Closed
Bug 1008244
Opened 7 years ago
Closed 7 years ago
Regression in 29: "Enter" key on <select> element no longer fires a keypress event
Categories
(Core :: DOM: Events, defect)
Tracking
()
People
(Reporter: bugs, Assigned: masayuki)
References
Details
(Keywords: regression, site-compat, testcase)
Attachments
(2 files, 1 obsolete file)
1.00 KB,
text/html
|
Details | |
2.23 KB,
patch
|
smaug
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release) Build ID: 20140509030227 Steps to reproduce: 1. Go to citizen science project (no account necessary) at http://www.notesfromnature.org/#/archives/calbug/transcribe 2. Click on "Got it. Let me transcribe!" button. 3. Enter "u" to select Country = United States 4. Press Enter key (Just close the page without submitting the record, and no harm is done to the project.) Actual results: Nothing happened. Expected results: Up to and including Firefox 28.0, pressing the Enter key is equivalent to clicking the green OK button. This is so for all similar pull-down menus, e.g., the following State and County fields. The same is true for the sister Herbarium project, also at http://www.notesfromnature.org. Testing with various Firefox releases before 29.0 under Windows 7, OS X, Ubuntu and Kubuntu, the Enter key moves to the next input field. With Firefox 29.0 and later, the Enter key has no effect under any of these OS's. Currently testing with 32.0a1 (2014-05-09). With Chrome and Rekonq (KDE WebKit-based browser) the Enter key continues to work.
Comment 1•7 years ago
|
||
(In reply to Graeme Hewson from comment #0) > User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 > Firefox/32.0 (Beta/Release) > Build ID: 20140509030227 > > Steps to reproduce: > > 1. Go to citizen science project (no account necessary) at > http://www.notesfromnature.org/#/archives/calbug/transcribe Any chance of a smaller testcase? I'm looking at this, but it's not even clear to me why enter should do this - it's hard to make out in the mass of minimized code, and the fact that it seems there's 1 JS file for all of the website (ie also the other projects, not just 'calbug'). > Expected results: > > Up to and including Firefox 28.0, pressing the Enter key is equivalent to > clicking the green OK button. This is so for all similar pull-down menus, > e.g., the following State and County fields. The same is true for the sister > Herbarium project, also at http://www.notesfromnature.org. > > Testing with various Firefox releases before 29.0 under Windows 7, OS X, > Ubuntu and Kubuntu, the Enter key moves to the next input field. With > Firefox 29.0 and later, the Enter key has no effect under any of these OS's. > Currently testing with 32.0a1 (2014-05-09). I can at least confirm that 32 is also broken. :-(
Component: Untriaged → General
OS: Linux → All
Product: Firefox → Core
Hardware: x86_64 → All
Comment 2•7 years ago
|
||
Argh, meant to needinfo - any idea about the possibility of a smaller testcase (or unminimized code?)
Flags: needinfo?(bugs)
![]() |
||
Comment 3•7 years ago
|
||
The behavior changed in this range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d650c07b547&tochange=9e06d42c2a6a That said, nothing in that range jumps out at me.
Comment 4•7 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #3) > The behavior changed in this range: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=9d650c07b547&tochange=9e06d42c2a6a > > That said, nothing in that range jumps out at me. Does to me. bug 935876. "Masayuki Nakano — Bug 935876 part.1 Don't consume key event on <select> element if it's never handled r= "
Updated•7 years ago
|
Summary: From Release 29.0, Enter key no longer acts as button click → Regression in 29: "Enter" key on <select> element no longer behaves as it did before
![]() |
||
Updated•7 years ago
|
Flags: needinfo?(masayuki)
Updated•7 years ago
|
status-firefox29:
--- → affected
status-firefox30:
--- → affected
status-firefox31:
--- → affected
status-firefox32:
--- → affected
Keywords: site-compat
Version: 32 Branch → 29 Branch
Reporter | ||
Comment 5•7 years ago
|
||
Sorry, I'm just an end user. I had a look at the code to try to reduce it to a test case before submitting this bug, but I'm not familiar with Javascript. I've submitted a bug at http://talk.notesfromnature.org/#/boards/BNN0000002/discussions/DNN00002b4 and asked if a developer there could engage with you.
Flags: needinfo?(bugs)
![]() |
||
Comment 6•7 years ago
|
||
Graeme, thanks for reporting this, both to us and them! We'll get it sorted out. ;)
Comment 7•7 years ago
|
||
(In reply to Graeme Hewson from comment #5) > Sorry, I'm just an end user. I had a look at the code to try to reduce it to > a test case before submitting this bug, but I'm not familiar with Javascript. > > I've submitted a bug at > http://talk.notesfromnature.org/#/boards/BNN0000002/discussions/DNN00002b4 > and asked if a developer there could engage with you. As Boris said, thanks for reporting it. It's useful either way, but I was worried about being able to narrow this down after spending 20 minutes trying to debug it and getting nowhere. Looks like Boris figured this one out already. :-) Separately, re: http://hg.mozilla.org/mozilla-central/rev/5b206fc5ecb6#l1.49 We historically, I *think*, didn't fire "change" on enter in a select box because of (now possibly gone, but you can see what happens when we change behaviour...) web code in the wild that did things like navigate the page onchange (language/region selectors were notorious for doing this), which meant using the arrow keys to change the selection wasn't reasonably possible if those fired a change event, which was an accessibility issue.
Comment 8•7 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #7) > didn't fire "change" on enter in a select box Ergh. s/on/until/
Assignee | ||
Comment 9•7 years ago
|
||
(In reply to Graeme Hewson from comment #0) > User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 > Firefox/32.0 (Beta/Release) > Build ID: 20140509030227 > > Steps to reproduce: > > 1. Go to citizen science project (no account necessary) at > http://www.notesfromnature.org/#/archives/calbug/transcribe > 2. Click on "Got it. Let me transcribe!" button. I don't see such button... Could somebody attach minimum testcase? > 3. Enter "u" to select Country = United States > 4. Press Enter key > > (Just close the page without submitting the record, and no harm is done to the project.) Who handles Enter key? Gecko or the web site? > e.g., the following State and County fields. The same is true for the sister Herbarium project, also at http://www.notesfromnature.org. And also I don't find it. Doesn't this web site check where the user access from? If Enter keypress event is handled by web site, it's site-compatible issue of D3E. Our <select> element now works as there is no keypress event which is deprecated in D3E. But I know all browsers fire a keypress event for Enter key even though it's not a printable key. I guess that we need to put off handling only Enter key at keypress event from keydown event (but except while dropdown is actually open). Anyway, I need small testcase for confirming the behavior.
Reporter | ||
Comment 10•7 years ago
|
||
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #9) > > 2. Click on "Got it. Let me transcribe!" button. > > I don't see such button... Could somebody attach minimum testcase? Try reloading the page. Otherwise, click through from the home page, http://www.notesfromnature.org/. Click "Start Transcribing" button, then Calbug, then "Start Transcribing". > Doesn't this web site check where the user access from? I don't believe so. > Anyway, I need small testcase for confirming the behavior. As I say, I'm just an end user. I hope a developer from the site can engage with you, but I suspect they're quite busy.
Comment 11•7 years ago
|
||
Here's a minimized testcase. Open your console, hit the U key followed by the Enter key. You'll find the keypress event is never fired on Firefox 29+.
Updated•7 years ago
|
Summary: Regression in 29: "Enter" key on <select> element no longer behaves as it did before → Regression in 29: "Enter" key on <select> element no longer fires a keypress event
Comment 12•7 years ago
|
||
Attachment #8420520 -
Attachment is obsolete: true
Assignee | ||
Comment 13•7 years ago
|
||
Thank you, Kohei-san, I believe that I can fix it easily.
Flags: needinfo?(masayuki)
Assignee | ||
Comment 14•7 years ago
|
||
First, for firing keypress event of Enter key on <select size="1">, we shouldn't consume keydown event of Enter key if its dropdown isn't open. This restores our old behavior which is same as other browsers in same condition. However, there is a difference. When Enter key is pressed when its dropdown is open, IE dispatches keypress event after change event. However, Chrome doesn't dispatch keypress event. I believe that we should NOT dispatch keypress event in this case like Chrome. It's current behavior and prevents double action. E.g., if browser works as IE and web apps handles Enter keypress event immediately after closing a dropdown, the Enter key press causes two or more actions. One is closing the dropdown. The other(s) is implemented by the web apps.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #8420965 -
Flags: review?(enndeakin)
Attachment #8420965 -
Flags: review?(bugs)
Assignee | ||
Comment 15•7 years ago
|
||
I think that this should be fixed as soon as possible because this may cause breaking some existing web apps.
Updated•7 years ago
|
Attachment #8420965 -
Flags: review?(bugs) → review+
Updated•7 years ago
|
Component: General → Event Handling
Comment 16•7 years ago
|
||
Important regression, tracking.
Comment 17•7 years ago
|
||
Comment on attachment 8420965 [details] [diff] [review] Patch I don't think I should be reviewing this.
Attachment #8420965 -
Flags: review?(enndeakin)
Assignee | ||
Comment 19•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e5b1060172be
Comment 20•7 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e5b1060172be
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Updated•7 years ago
|
Component: Event Handling → DOM: Events
Reporter | ||
Comment 21•7 years ago
|
||
I confirm the problem I reported initially is fixed in 32.0a1 (2014-05-17).
Assignee | ||
Comment 23•7 years ago
|
||
Oh, yeah. I'll confirm the patch which can work with branches tomorrow and request approval. Thank you for the ping.
Flags: needinfo?(masayuki)
Assignee | ||
Comment 24•7 years ago
|
||
Comment on attachment 8420965 [details] [diff] [review] Patch [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 935876 User impact if declined: On <select size="1"> element, keypress event of Enter key is never fired because preceding Enter keydown event is consumed without any action. This may cause Enter key handling is broken on a lot of web sites when such select element has focus. Testing completed (on m-c, etc.): Landed on m-c. Risk to taking this patch (and alternatives if risky): Not so risky. This patch makes select element just ignore Enter keydown event if dropdown is in dropdown mode and dropdown is closed. String or IDL/UUID changes made by this patch: Nothing.
Attachment #8420965 -
Flags: approval-mozilla-beta?
Attachment #8420965 -
Flags: approval-mozilla-aurora?
Updated•7 years ago
|
Attachment #8420965 -
Flags: approval-mozilla-beta?
Attachment #8420965 -
Flags: approval-mozilla-beta+
Attachment #8420965 -
Flags: approval-mozilla-aurora?
Attachment #8420965 -
Flags: approval-mozilla-aurora+
Comment 25•7 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/86a9ca4963f7 https://hg.mozilla.org/releases/mozilla-beta/rev/ba6d1a086b1a
Updated•7 years ago
|
status-b2g-v1.4:
--- → fixed
status-b2g-v2.0:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•