User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce: I see something has changed between Firefox 48 and 49 in regards to select elements and the onchange event. Couldn't find any reference in the 49 release changelog though. I see a change in 48.0.2, not sure if related. For years, Firefox has been the only major browser to correctly implement the onchange event, specifically when related to keyboard interaction. The issue has been discussed at length for the last 15 years, see for example https://bugzilla.mozilla.org/show_bug.cgi?id=126379 and https://bugzilla.mozilla.org/show_bug.cgi?id=969068 it's very evident especially on Windows. Keyboard-only users and screen reader users need to explore the content of a select to make a decision and they use arrow keys to do so. Firing the onchange event while still exploring the select contents isn't ideal. Worth noting MDN still refers to the correct behavior: https://developer.mozilla.org/en-US/docs/Web/Events/change ... For example, keyboard navigation in <select> elements never fires a change event in Gecko until the user hits Enter or switches the focus away from the <select> (see bug 126379). Actual results: Test case: http://codepen.io/afercia/full/wJxEbz/ Better to test on Windows, where focusing the select and using arrow keys doesn't open the select. - use the keyboard to focus the select - do not open the select - user down and up arrow keys to change the options - the onchange event is fired at each arrow keys press Expected results: - when using the keyboard, the onchange event should fire only when the the option has changed *and* the select gets blurred.

Is this with or without e10s (multiprocess FF)? I guess with e10s.

Flag needinfo on Andrea for comment 1.

Happy to help if you give me instructions on how to check or enable/disable e10s. I guess there's some flag in about:config? Anyway, what I've done for testing: I've just downloaded from your FTP several versions (win64), installed them in different folders on Windows 10 with separate, clean, profiles, and compared the different behaviours. The difference between 48 and 49 is very clear.

To check if you are using e10s, aka multiple process, you could visit the "about:support" page and check the row of "Multiprocess Windows" in the table of "Application Basics." You could easily turn the e10s on or off by visiting the page "about:preferences". In the panel of "General", you could (un)check "Enable multi-process".

Tested again, on both macOS Sierra and Windows 10, FF 52.02. On macOS it was: "Multiprocess Windows 0/1 (Disabled by add-ons)" (aXe DevTools and Web Developer toolbar) On Windows 10 it was: "Multiprocess Windows 0/1 (Disabled by accessibility tools)" (I guess because I often use NVDA for testing) In both cases I'm able to reproduce the change event firing on the Codepen. Then I've disabled any add-ons on FF macOS and reset `accessibility.lastLoadDate` on FF win so now in about:support I have on both platforms "Multiprocess Windows 1/1 (Enabled by default". That doesn't make a difference, I can still reproduce the change event firing. On macOS, to reproduce the Windows behaviour (i.e. the select doesn't open when focused with a keyboard and then using the arrow keys) all I have to do is keeping `Fn` pressed while using the arrows. In both cases, the event fires while changing the options and the select is still focused. It should fire only when the select gets blurred. > You could easily turn the e10s on or off by visiting the page "about:preferences". In the panel of "General", you could (un)check "Enable multi-process". I can't see that preference anywhere, I guess it's only on the Nightly?

Mike, do you know what changed with <select> for e10s and/or that fancy re-design you were mentoring?

(In reply to Andrew Overholt [:overholt] from comment #6) > Mike, do you know what changed with <select> for e10s and/or that fancy > re-design you were mentoring? Yes, I do. We re-arranged things so that the e10s and non-e10s <select> could use the same codepaths, and bug 1331725 exists to flip the pref so that non-e10s uses the e10s path. Unfortunately, there are (I believe) some accessibility issues (bug 1309271) preventing us from flipping that pref.

The preference, for what it's worth, is dom.select_popup_in_parent.enabled

David, should this block some e10s-a11y bug?

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information