Regression in 29: "Enter" key on <select> element no longer fires a keypress event

RESOLVED FIXED in Firefox 30

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bugs, Assigned: masayuki)

Tracking

({regression, site-compat, testcase})

29 Branch
mozilla32
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox29 wontfix, firefox30+ fixed, firefox31+ fixed, firefox32+ fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

5 years ago
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

5 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

5 years ago
Argh, meant to needinfo - any idea about the possibility of a smaller testcase (or unminimized code?)
Flags: needinfo?(bugs)
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

5 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= "
Blocks: 935876
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 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
Flags: needinfo?(masayuki)
Reporter

Comment 5

5 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)
Graeme, thanks for reporting this, both to us and them!  We'll get it sorted out.  ;)

Comment 7

5 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

5 years ago
(In reply to :Gijs Kruitbosch from comment #7)
>  didn't fire "change" on enter in a select box

Ergh. s/on/until/
(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

5 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.
Posted file testcase (obsolete) —
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+.
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
Thank you, Kohei-san, I believe that I can fix it easily.
Flags: needinfo?(masayuki)
Posted patch PatchSplinter Review
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)
I think that this should be fixed as soon as possible because this may cause breaking some existing web apps.
Attachment #8420965 - Flags: review?(bugs) → review+
Component: General → Event Handling
Important regression, tracking.

Comment 17

5 years ago
Comment on attachment 8420965 [details] [diff] [review]
Patch

I don't think I should be reviewing this.
Attachment #8420965 - Flags: review?(enndeakin)
Duplicate of this bug: 1011223
https://hg.mozilla.org/mozilla-central/rev/e5b1060172be
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Component: Event Handling → DOM: Events
Reporter

Comment 21

5 years ago
I confirm the problem I reported initially is fixed in 32.0a1 (2014-05-17).
We want the patch on branches too, I think?
Flags: needinfo?(masayuki)
Oh, yeah. I'll confirm the patch which can work with branches tomorrow and request approval. Thank you for the ping.
Flags: needinfo?(masayuki)
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?
Attachment #8420965 - Flags: approval-mozilla-beta?
Attachment #8420965 - Flags: approval-mozilla-beta+
Attachment #8420965 - Flags: approval-mozilla-aurora?
Attachment #8420965 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.