Dropdown not working on website: find the fault

A dropdown has to survive three things: the page layout, the order of the clicks and the data behind it. A cookie banner or a sticky header can sit on top of the list, so the tap lands on the banner and the list never hears it. A custom list can close on the press that was meant to choose an option, because the press counts as a press outside the toggle. A list filled from a slow or failed request shows nothing at all. The owner tests on a laptop with the page already loaded and a mouse, so none of these show up.

• Is the dropdown a native select, or a custom list built from boxes and links? The checks differ.
• Tap the toggle at phone width. Is any part of the open list under a banner or a sticky header?
• Pick an option, then read the displayed label. Does the box show the choice, or the old value?
• Does the list fill from a request? An empty list usually means the request failed or is still running.
• Tab to the dropdown and use the arrow keys and Enter. A list that ignores the keyboard fails those visitors too.

A native select is the browser's own control. On a phone it opens the system picker, and on a laptop it opens a small list. It fails rarely, and when it does, the cause is usually the script that reads it. A custom dropdown is a list built from boxes or list items, with styles and a toggle that someone wrote. It fails often, because it depends on click order, stacking order and the layout around it. The visitor sees the same thing in both cases: the box is tapped and nothing is chosen. Find out which kind is on the page first, because each needs different checks.

Open the page in a laptop browser with device mode set to phone width, and open the Console. Tap the dropdown's toggle, then run document.elementFromPoint with the x and y position of the option. The element it returns is the one that receives the tap. If it is a cookie banner, a sticky header or a promotion layer, the list is open but covered. If it is the option itself, the click reaches the list, and the fault is in the handler. Device mode runs Chrome on your laptop, not the phone's own browser, so confirm the result on the phone before you rely on it.

This is the most common fault in a custom dropdown. The list listens for a press anywhere on the page, and it closes whenever a press lands outside the toggle. A press on an option lands inside the list, but a careless handler can still count it as outside. Some scripts close the list on the press itself, then remove the options from the page. The click that follows has nothing to land on, so no option is picked, and the visitor sees the list flicker shut. The fix is to ignore presses inside the list when it decides to close, and to set the value in the option's own click handler.

Signup flow testing

A second dropdown that depends on the first is often disabled until a real value is chosen. If the first one's placeholder, such as Choose one, counts as a value, the second list goes active with nothing in it. If the first value is set by the script but no change event fires, the second list never learns that the first one changed. Check this by picking the first option, then reading the disabled attribute on the second dropdown in the Elements panel. A simulated visitor makes the same choices in order, and the report names the step where the second list stayed empty, with a screenshot.

A cookie banner, chat bubble or sticky header added in a later release can sit over the list and take the taps. Rerun the same simulated visitor after each change to the layout, in a phone-sized browser. If the dropdown sits behind a login, test it with a test account, and check each preview deploy before the change goes live.