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

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Graeme Hewson]

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

[:Gijs (he/him)]

(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. :-(

Comment 2

[:Gijs (he/him)]

Argh, meant to needinfo - any idea about the possibility of a smaller testcase (or unminimized code?)

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

[:Gijs (he/him)]

(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= "

Comment 5

[Graeme Hewson]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Graeme, thanks for reporting this, both to us and them!  We'll get it sorted out.  ;)

Comment 7

[:Gijs (he/him)]

(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

[:Gijs (he/him)]

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

Ergh. s/on/until/

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still not recoverd perfectly)]

(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.

Comment 10

[Graeme Hewson]

(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

[Kohei Yoshino]

Attachment: testcase

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+.

Comment 12

[Kohei Yoshino]

Attachment: testcase, works on non-Gecko browsers

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still not recoverd perfectly)]

Thank you, Kohei-san, I believe that I can fix it easily.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still not recoverd perfectly)]

Attachment: Patch

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.

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still not recoverd perfectly)]

I think that this should be fixed as soon as possible because this may cause breaking some existing web apps.

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Important regression, tracking.

Comment 17

[Neil Deakin]

Comment on attachment 8420965 [details] [diff] [review]
Patch

I don't think I should be reviewing this.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still not recoverd perfectly)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e5b1060172be

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e5b1060172be

Comment 21

[Graeme Hewson]

I confirm the problem I reported initially is fixed in 32.0a1 (2014-05-17).

Comment 22

[Olli Pettay [:smaug]]

We want the patch on branches too, I think?

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still not recoverd perfectly)]

Oh, yeah. I'll confirm the patch which can work with branches tomorrow and request approval. Thank you for the ping.

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still not recoverd perfectly)]

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.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/86a9ca4963f7
https://hg.mozilla.org/releases/mozilla-beta/rev/ba6d1a086b1a

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/ba6d1a086b1a