Created attachment 623494 [details] firefox_select_bug_2012.html User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120423122843 Steps to reproduce: Problem with: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 BuildID: 20120423122843 Issue 1: Test HTML, see bug (or ANY <select>): https://bugzilla.mozilla.org/show_bug.cgi?id=691725 1) [tab] until you've selected a... <select> 2) Press [spacebar] OR [enter]. 3) No dropdown appears.... Issue 2: 1) [tab] until you've selected a... <select> 2) Press up/down arrows. 3) It won't fire the onchange, until you've pressed enter. Please note: The attached file is quick-n-dirty. When using good written JS, it has the same issue. This problem is also verified in Safe Mode. Actual results: Nothing, see 'what did I do' ;] Expected results: Issue 1: Drop-down menu should appear. On the same way as when you'd trigger an click with your mouse. Issue 2: The onchange should be fired directly. Just like Chromium, Internet Explorer, Opera or any other browser. And that's even how Firefox used to behave... So what broke this?
Attachment #623494 - Attachment mime type: text/plain → text/html
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15.0 Firefox/15.0a1 Confirming, though this doesn't seem to be a recent regression (same behavior in 4.0.1). The drop-down menu isn't selectable by tab and space/enter. Neither is onchange fired directly with tab + up/down arrows. Ideally, the two issues should be tracked in separate bugs. Chrome and Opera perform valid operations for the above mentioned keyboard combinations.
Status: UNCONFIRMED → NEW
Component: Untriaged → Keyboard Navigation
Ever confirmed: true
OS: Linux → All
QA Contact: untriaged → keyboard.navigation
Hardware: x86_64 → All
Version: 12 Branch → Trunk
About issue 2, maybe duplicate of bug 126379
(In reply to Virgil Dicu [:virgil] [QA] from comment #1) > Confirming, though this doesn't seem to be a recent regression (same > behavior in 4.0.1). This made me search for an old Firefox version. Confirming issue(s) at: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20101013 Ubuntu/9.04 (jaunty) Firefox/3.6.11 I'm not sure if I've seen this issue in a earlier stage. Maybe I did notice that something was different/wrong. But can't find out, as all the bugs that I've reported are in some internal bugtracker at a former employer. This changed my testing procedure (uh, the file that describes the procedure). #155 (and other comments) in bug 126379 (that Alice0775 White linked): > For users who need to navigate using the keyboard alone, as you point out, they > already have the possibility to open the drop-down box with Alt-Down, navigate > it and press Enter. Ok, that (Alt+DownPointer) works great. But.. did I just learned that, or did I "forget" the inner workings of Firefox? ;-) Smells like a 'custom' keyboard combination. Can someone explain me which other OSes/Applications use that keyboard combination for selecting stuff in drop-down lists? I get the following results, after some more testing: Opera 9.62 / 9.80 handles: - Space, triggers keyup event. And opens the dropdown. * Moving through the menu triggers keyup events. - Alt+DownArrow opens the (dropdown)menu, and triggers onkeyup after releasing keys. * Moving through the menu triggers keyup events. - Enter does an onchange + formsubmit event. Firefox 3.6.11 handles: - Space, triggers keyup event. Does not drop down the menu. - Alt+DownArrow opens the (dropdown)menu, and triggers onkeyup after releasing keys. * Moving through the dropdown triggers keyup events. * Pressing [tab] triggers onchange (because of lost focus). - Enter after changing the <select> option, without the dropdown (via alt+arrowdown), triggers: keyup (and onchange if changed). Firefox 12 handles: - Space, triggers nothing. - Alt+DownArrow opens the (dropdown)menu. * Moving with arrows over items, won't trigger anything. * Pressing [enter] on the <select> triggers onchange (in dropdown modus, and (drop)hidden). * Pressing [tab] triggers onchange (because of lost focus), and moves to next item. - Enter, triggers onchange if changed. Chromium 18 handles: - Alt+ArrowDown does nothing. - Space, opens the (dropdown)menu. But does not trigger any event. * Moving with arrows over items, does not trigger events. * Pressing space again, does not trigger events. * Pressing [tab] won't trigger to the next item. But does onkeyup+onchange on the <select>, and keeps focus at select. * Pressing [enter] triggers onkeyup+onchange. VLC in XFCE4 (Xbuntu 11.10) handles: - Space will open the menuitem * Moving with arrows will select the item. * Pressing enter will close the menuitem. Doing a selection. - Moving without opening the <select>-ish OS drawed box, selects items directly. My point is: All browsers should be "consistent". At least on a basic level as keyboard input. They aren't... Most Operating Systems handle (afaik) via space/enter/arrows combination. So why did firefox choose to implement the <select> in this way? I've never used Alt+ArrowDown in ANY Operating System (with GUI), and I've seen most OS-es. So this is something, I can't get my head around. But it could be me ;-) > W3Schools defines: > Keyboard Events > Valid in all elements except base, bdo, br, frame, frameset, head, html, iframe, meta, param, script, style, and title. Maybe W3/WhatWG describes that in a better way, but I'm expecting the above. So when a user does something with an <option> or <select>, I want to be able to use that in JS. Without Firefox killing my keyboard events. An keyup is an keyup. No matter where in that object it would be placed. Key is key. And Firefox at least needs to trigger them correctly (the onchange trigger is another discussion, therefore see bug 126379). Is there something like a (G)UI defacto standard, to compare this behavior with? Excluding W3/WhatWG, because they can be wrong (in implementation / interpretation, (personal)opinion or whatever). Then it would be possible to verify W3/WhatWG' interpretation. (In reply to Alice0775 White from comment #2) > About issue 2, maybe duplicate of bug 126379 Yes, pretty much. And even issue 1 is (semi)described in there, if I read correctly (why didn't show that bug up, in DuckDuckGo..). Maybe this 'entire' bug is a duplicate of 126379?! This problem is quite annoying, when your trying to overwrite the Operating System behavior of an <select> box. Because you can't design (with CSS) the system calls for that objects. It works great when someone uses a mouse, but keyboard selection just will be ****. This issue 'missing keyup event' started somewhere after version 3.6.11. Because of this, I can't display the change (the underlayed div, which should contain the text of current 'active' item under selection. the <select> gets opacity 0, and is correctly selectable/clickable). And I'm pretty sure that this worked when I implemented this functions X years ago. Ofc., a solution would be to drop this method, build the select from scratch using JS. And then completely hide the original <select>. This way I can recreate the correct keyboard inputs, which support the onkeyup event. But this also results in browser specific code (only for Firefox...). Because for mobile devices (Android and such) I want the original <select> OS call to appear (the dropdown action, or popup for Android). Because this OS call is usefull. And the worst of this solution is, that a user would expect to happen something in way X in his browser, but lacks general experience. So my 'fixes' could be worse, for the experience of the user. So I don't want to talk about this. I just want: - The spacebar to 'open' the <select> - It should fire the key* events, like ALL other browsers.
Oh ****. Just fixed the onkeyup events in Chromium 18 + Firefox 12 via onselect event. Issue 2 is SOLVED.
Is there any update on Issue 1?
You need to log in before you can comment on or make changes to this bug.