307345 - Escape key does not cancel html select change

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Mike Caines]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050906 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050906 Firefox/1.4

In Firefox 1.0x pressing the escape key cancelled any change the user made to
the selection of an HTML select (single / drop-down), and closed the select. In
Deer Park the select is closed but the changes are not cancelled.

Reproducible: Always

Steps to Reproduce:
1. Open the "Component" select at the top of this page
2. Use the keyboard to move the selection down a few options
3. Press the escape key

Actual Results:  
The select is closed with the new option selected

Expected Results:  
The select is closed with the old option selected

Comment 1

[Scott MacGregor]

mikecaines, can you confirm if this regression was in deer park alpha 2 or just
showed up recently?

Comment 2

[Mike Caines]

This behaviour is evident in Deer Park alpha 2, but not Firefox 1.04. I'll try
and track down the exact date later today.

Comment 3

[Wayne Mery (:wsmwk)]

Bug 244761 related?

Anyway this goes way back. The following the leaves a big regression window.,
but FWIW ...

works 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041103
Firefox/1.0RC2

fails
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041222
Firefox/1.0+
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050112
Firefox/1.0+
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050228
Firefox/1.0+
DPa1 and DPa2

Comment 4

[Aaron Leventhal]

If it helps here are the recent cvs checkins (with dates) to nsListControlFrame,
where I'm betting the problem occured.

http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/layout/forms/nsListControlFrame.cpp

Comment 5

[Aaron Leventhal]

We need at least the month it broke on the 1.8 branch.

Comment 6

[Mike Schroepfer]

Will consider for 1.5b2.

Comment 7

[Gábor Stefanik]

This bug also happens if you click on an empty area of the browser (instead of
pressing Escape) after keyboard-moving the selection.

Comment 8

[Uri Bernstein]

Confirming on OS X => All/All.

This was already broken on the trunk on 2004-07-01:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040701
Firefox/0.8.0+

Comment 9

[Uri Bernstein]

... but still worked on Mozilla 1.8a1:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520

So we have a 40-day regression window.

Comment 10

[Uri Bernstein]

Hmmm... bug 244761?

Comment 11

[Aaron Leventhal]

Neil, this is probably you - see comment 10.

Comment 12

[[e-mail]]

(In reply to comment #0)
>Actual Results:  
>The select is closed with the new option selected
Interestingly I get the same results in IE and native Windows controls too.

Comment 13

[Aaron Leventhal]

(In reply to comment #12)
> (In reply to comment #0)
> >Actual Results:  
> >The select is closed with the new option selected
> Interestingly I get the same results in IE and native Windows controls too.

True! In that case I suggest WONTFIX at least for Windows. We should act like
native controls.

Comment 14

[Aaron Leventhal]

Can someone test on Gnome, KDE and OS X to see what Escape does for drop downs?

Comment 15

[Uri Bernstein]

On OS X (Safari), ESC cancelles the selection, i.e. the previous selection is
restored.

Comment 16

[Aaron Leventhal]

Don't we already use native widgets in Gecko on OS X? I would think we'd
therefore get it right there. Uri, can you confirm that?

If so, this would be only a Linux bug.

Comment 17

[Aaron Leventhal]

The standard KDE combo box widget returns to the previous combo box choice if
you hit Escape.

So far we have:
Gecko HTML: Escape chooses
Gecko XUL: Escape cancels
Windows: Escape chooses
KDE: Escape cancels
OS X (Safari): Escape cancels
Gnome: ?

Comment 18

[Aaron Leventhal]

Gnome filepicker: escape cancels

It seems that things are very inconsistent everywhere.

Even though Windows doesn't cancel the choice on Escape, I think we should
eventually fix that in Mozilla. Escape traditionally means cancel my data entry.
This is a very useful thing in the case of a combo box. A keyboard only user
should be able to go into a combo box and read all the choices without affecting
what's in it.

Comment 19

[Uri Bernstein]

(In reply to comment #16)
> Don't we already use native widgets in Gecko on OS X? I would think we'd
> therefore get it right there. Uri, can you confirm that?

No, we don't, not even on the latest trunk.

Comment 20

[Aiko]

Windows is inconsistent here, for example pressing ESC in IE's address bar or in
Wordpad's font select cancels the selection. Please restore the old behaviour on
Windows, too.

Comment 21

[Aaron Leventhal]

(In reply to comment #20)
> Windows is inconsistent here, for example pressing ESC in IE's address bar or in
> Wordpad's font select cancels the selection. Please restore the old behaviour on
> Windows, too.

Interestingly, those are both editable combos. You can have a caret in the entry
field and type stuff in it.

Comment 22

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 23

[Mats Palmgren (inactive)]

Comment on attachment 266489 [details]
Testcase #1

This testcase is about selection through mouse movement over the menu items
and it was fixed by bug 346043.

That's not what this bug is about though, which is about keyboard navigation
through the drop-down menu, followed by Escape.

Comment 24

[Mats Palmgren (inactive)]

It's been almost a decade since it was investigated how other UAs and desktop environments
behave, so it's probably a good idea to investigate it again before changing anything.

Comment 25

[Emil Pasca [:emilpasca]]

User Agent:  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0

This issue has been tested on Win 10 x64, Win 7 x64, with the latest Firefox release (46.0.1, Build ID: 20160502172042) and the latest Nightly(49.0a1, Build ID: 20160526030223) and it is reproducible. 
Following the STR from comment 0 and the testcase from attachment 8606895 [details], when pressing "Esc" key the dropdown closed and the last option selected is displayed in the cell. The same behavior was encountered on other browsers as well (Chrome, Opera, Safari, Edge and Internet Explorer).
When testing this on  Mac OS 10.11 and Ubuntu 14.04 using the latest Nightly, the issue isn't reproducible. Pressing the "Esc" key, will close the dropdown but the old option will be displayed in the cell.

Comment 26

[Mats Palmgren (inactive)]

Attachment: testcase

FYI, Chrome is supported on several platforms so you need to say which one
you tested.  Opera is probably not worth testing anymore since it uses
the same underlying technology as Chrome.

For Firefox you need to say whether you tested with or without e10s
enabled, because we have different combobox implementations for those
and may have slightly different behavior.

I think you made a mistake when testing Safari on OSX.  Escape closes
the menu without changing the value as far as I can tell.  That's
the behavior we also want in Firefox on OSX.

I tested native GTK comboboxes on Ubuntu and they seem to behave the same
as on OSX.  So that's probably the behavior we want in GTK Firefox (on
Linux, *BSD etc) as well.

We should also test if and when the 'change' event is dispatched when
comparing our behavior with other browsers.  Here's a test that logs
those events.  For example, using Firefox on Linux, when selecting values
in the dropdown menu using UP/DOWN keys and then typing Escape, we display
the last selected value but we don't dispatch any 'change' event until
the control loses focus.  Chrome on Linux dispatches the 'change' event
directly when hitting Escape.

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.