Why does Selenium's Select class throw UnexpectedTagNameException on a dropdown built from div elements?

## The check the constructor performs `Select` decides whether it will work with your element in its very first two statements: ```java String tagName = element.getTagName(); if (!"select".equalsIgnoreCase(tagName)) { throw new UnexpectedTagNameException("select", tagName); } ``` That comparison is the whole gate. It is **case-insensitive**, it runs before any other work, and nothing else about the element is considered: not its CSS classes, not its ARIA role, not whether it visually behaves like a dropdown when the applicant clicks it. Construction either succeeds or fails, so you never end up holding a half-working wrapper. ## What the exception carries `UnexpectedTagNameException` lives in the same `org.openqa.selenium.support.ui` package and extends `WebDriverException`, so it is **unchecked** — nothing forces you to catch it, and it surfaces as an ordinary test failure. Its message is built from the two tag names, giving output such as `Element should have been "select" but was "div"`. That single line tells you the control on the parking-permit renewal form is not a browser dropdown at all, which is usually more valuable than the failure it prevented. ## Why the class cannot be taught to drive a scripted listbox Every method on `Select` is defined in terms of things only a real `<select>` has: - `getOptions()` is literally a search for `option` descendants of the wrapped element; a panel of `div` rows has none. - The constructor reads the `multiple` content attribute to answer `isMultiple()`; a scripted widget has no such attribute. - `getAllSelectedOptions()` and `getFirstSelectedOption()` filter on **selectedness**, the state the WebDriver protocol reports for an option element. A `div` has no selectedness — at best it has a class name or an `aria-selected` value, which is a different thing that the protocol does not report as selected. - Changing the choice relies on the protocol's dedicated option branch of the click algorithm, which scrolls the containing `<select>` into view and updates the option's selectedness. A `div` takes the ordinary pointer path instead. | What `Select` needs | Real `<select>` | Scripted listbox | |---|---|---| | `option` descendants | present | absent — `div`, `li` or `span` rows | | `multiple` attribute | present or absent, readable | not defined | | reported selectedness | yes, per option | no, only page-owned styling or state | | option-specific click handling | defined by the protocol | ordinary element click path | ## Telling the two apart on the renewal form 1. Inspect the permit-type control in the browser's element inspector. A real one is a `<select>` element with `<option>` children that exist even while the list is closed. 2. A scripted one is usually a button or text box plus a panel of rows that is inserted into the DOM only while the list is open. 3. A real `<select>` opens the operating system's own popup, which the page's CSS cannot restyle; a scripted one is styled entirely by the page. 4. The tag check itself is the cheapest test of all. Constructing a `Select` around the control either succeeds or tells you, in one line, which tag you actually have. ## What you do instead There is no configuration, subclass or flag that makes `Select` accept a scripted widget, and there is no point trying: a wrapper whose every method is defined over `<option>` elements has nothing to work with. A scripted listbox is a collection of ordinary elements and is driven with the ordinary element commands your suite already uses for ordinary elements. Treat `UnexpectedTagNameException` as **information** rather than an obstacle — it is the fastest possible signal that you are looking at a custom widget. The one thing not to do is to reach for a workaround that fakes the outcome. Setting an `aria-selected` value or a class name on a row makes the page *look* chosen without the widget's own code ever running, so the renewal form's state, its hidden input and its validation are all left behind. The check exists to stop a wrapper producing that kind of half-truth, and the same reasoning applies to whatever you write in its place. ## The case that is often confused with it A different failure looks similar and is not the same problem. Some designs keep a real `<select>` in the DOM but hide it behind a styled overlay. There the tag name is right, so `new Select(...)` **succeeds**; the failure arrives later, when `selectByVisibleText` refuses with `UnsupportedOperationException("You may not select an option in invisible select")`. The two messages say different things: `UnexpectedTagNameException` means "this is the wrong kind of control", while the `UnsupportedOperationException` means "this is the right control, but it is not currently visible". Reading the exception type before reaching for a workaround saves the hour usually spent on the wrong one.