Example of a select menu event handler not being fired.

Setup: When the page loads, focus is brought to the select menu. (If the smart memory of the browser then removes the focus from the select menu because such was the previously-visited state of the page, then please click on the select menu to bring focus to it.)

Problem description: At this point, when the arrow keys are used to change the selection (or the mouse), the onchange() event handler of the select object should be fired. This would result in the selected value dynamically changing its text to reveal " (selected)" at the end of its original value.

Actual behavior is not observed. Only the mysterious action of clicking at a spot on the page outside of the select menu will complete the onchange() event and fire the handler.

Criticism of this bug:

I can think of two things.

According to http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html, Objects that implement the HTMLOptionElement interface have a text value which is read-only. So this bug report shouldn't work, anyway. But clearly, this was a short-sighted specification (and inconsistent within itself, since it allowed much more radical dynamic changes to the contents of a select menu within a form, by the add() and remove() methods). So I have taken the liberty of using an invalid example, which happens to be the most instructional demo of this bug.
A more legitimate concern is select menus which are used for page navigation. Selecting a new option navigates to the selected page. Using the arrow keys is a wonderful way of visiting all of the website in order. (And the smart memory of the browser which I mentioned before in an irriated way becomes a good thing--in fact, only a finger on the keyboard is needed to go through the entire collection which is shown by the select menu, because at each page load the previous selection is active, and focus is brought once again to the same navigational selection menu.)
Benefit if the bug is fixed: When I originally noticed this bug, it was because I wanted to navigate this way, simply hitting the arrow key while I went through a list of texts and pictures at http://www.kcfn.net/bible-memory.html. However, this beautiful example of the bug was changed at the end of the week when the promotional item was done.

Problems if the bug is fixed: However, this exact same scenario is the only possible situation in which I can imagine a problem occuring due to the new behavior when the bug is fixed (note, however, that IE does fire the onchanger handler when

This gives a fairly complete description of the bug and a discussion of the pros and cons of fixing the bug.

Basically, the technical decision is whether or not onchange() is fired when the element is changed (which seems logical, but may cause problems); or only if it is fired when the element is changed and then afterwards focus is removed from the select element and the focus set someplace else. This latter behavior causes much larger problems in my opinion, in the case where the select element is the sole form input field within a form, and its entire purpose is to provide behavior to the page through onchange() events.

For example, the expected operation of clicking on a new item quantity and seeing an updated total, must instead consist of selecting a quantity, "finalizing" it (which appears to be the only goal in not firing the event handler at once), and then clicking elsewhere at a random location in the page. This procedure, although it makes logical sense to someone who understands the event handler, is confusing to users of pages like this: https://providenceproject.com/order/form.html.

As I said, the only time when firing the event handler with each selection (instead of only at the "final" selection) would seem to be hurtful is when navigation away from the page would result. It is possible that an undesired intermediate selection would whisk someone off to the page that they didn't really want to go to. Yet this problem is overwhelmed by the fact that in common navigation systems such as this, the select menu is the only form field. Thus, if the user does not understand the need to click elsewhere (to show that his choice is "finalized"), nothing will happen. What would result is apparent "disregard of user input," which is a more serious issue than "confusion of user input."

So, altogether I think the bug needs to be fixed. That's why I am taking the time to write a test case after the original example was taken away. Sorry that I was busy in the interim with summer classes.

Since I am concerned that the proposed fix may perhaps be interfering with major expected behavior of the browser as it is currently used, I have tried to provide a longer report than usual.