1195200 - [e10s] <select> pull down menu ignores selections made w/ keyboard, if user clicks outside of menu

Status: REOPENED

(Core :: Widget, defect, P3)

Description

[Sylvestre Ledru [:Sylvestre]]

Recently I have a change of behavior in shortcut usages.

Let's take bugzilla's tracking flag as an example.

1) Edit the tracking flags
2) Click on status-firefox40
3) Press the key "a" to select "affected"
4) Click outside of the pull down menu
=> without e10s: "affected" is selected

The previous value remains selected.

I guess it is the same issue but I select a pull down menu, click again on it to close the list, press "f". It will work the first time (ie selecting "fixed") but I cannot change it later (example: "w" to select "wontfix")

40.0.2 is unaffected. I am not 100% sure but I started experiencing this issue but I started to use e10s

Comment 1

[Sylvestre Ledru [:Sylvestre]]

And I had this issue before the switch to GTK3.

Comment 2

[Julien Wajsberg [:julienw]]

I have this issue in Fx41 as well (non-GTK3, e10s).

Comment 3

[Neil Deakin]

The e10s version of <select> matches the OS behavior I see on Linux. The non-e10s version of <select> does not.

Comment 4

[Jim Mathies [:jimm]]

based on comment 3, please reopen if you disagree.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

[Tracking Requested - why for this release]:

Using again a e10s Firefox (I was running 42 as I was the owner of this release, therefor, non-e10s), indeed, I do not agree.
The behavior of Firefox changed, it is what matters to me (moreover, I am not sure the assertion that it is the OS behavior is correct). Same rational as in bug 1176929.
I think this should be addressed before e10s is proposed to beta users under GNU/Linux. Just talking for me but, just that bug alone is a big enough driver for me to disable e10s on my system. (I am using Bugzilla status flags all day long).

Comment 6

[Tracy Walker [:tracy]]

On Mac, <select> menus are also behaving distinctly differently on e10s vs non-e10s.

on e10s, there is a check mark identifying which item is selected.  using the keyboard, to quickly navigate to an item in the list, doesn't select next matching item, but rather sets focus to that list item.  In order to select the highlighted/focused item, you must hit the enter/return key.

on non-e10s, there is no check mark. Using the keyboard immediately selects the next matched item.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking since this is a recent regression. I don't think I need to track for 43 since we are only planning to have e10s running in 43 beta for a few users as an experiment.

Comment 8

[Neil Deakin]

We could try to match the old <select> behaviour but that behaviour is arbitrary and doesn't match any system dropdown widget. Yes, there will be some changes for those used to the non-e10s select widget, but I believe in the long-run we should strive to match the OS behaviour as much as possible. I don't think we should prioritize this bug.

Note that the correct way to accept the change in comment 0 is to press Enter at step 4 not click outside the menu.

Comment 9

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Jim, is this something we plan to fix for FF44? Its a tracked bug and therefore poking to see if we have a fix ready for uplift. Thanks!

Comment 10

[Jim Mathies [:jimm]]

(In reply to Ritu Kothari (:ritu) from comment #9)
> Jim, is this something we plan to fix for FF44? Its a tracked bug and
> therefore poking to see if we have a fix ready for uplift. Thanks!

no, it's not tracking an e10s milestone so we aren't working on it.

Comment 11

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Thanks Jim! Setting this to wontfix for 44. Please update status if the fix is ready for uplift to Beta44.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Neil Deakin from comment #8)
> We could try to match the old <select> behaviour but that behaviour is
> arbitrary and doesn't match any system dropdown widget.

Pushing back on this slightly:
* The old <select> behavior *does* match Win10 system dropdown widgets (and most of our users are on Windows).
* The old <select> behavior matches what other browsers do (except on MacOS)
* The old <select> behavior is baked into users' muscle memory (for users that fill out web forms at least), and changing it is a bit destabilizing.

I tested the following browsers and they all give EXPECTED RESULTS with this bug's STR:
 Win10:
   Edge, IE11, Chrome 47, Firefox 43 (i.e. all popular modern browsers)
   System
 Mac OS El Capitan:
   Firefox 43
 Ubuntu 15.10:
   Chrome 49dev, Firefox 43, Firefox Nightly w/ e10s disabled

...and only these browsers have ACTUAL RESULTS:
  Mac OS El Capitan:
   Chrome 43, Safari 9
  [All platforms]:
   Firefox 45/46 with e10s enabled.
(version numbers are somewhat arbitrary; it's just what I have handy)

So. It seems this behavior is not really arbitrary -- Mac system dialogs behave one way (and other browsers on that platform have aligned to that), and Windows system dialogs behave a different way (and all browsers on that platform have aligned to that, and we've aligned to that on every platform)

So I wonder if we should reconsider the prioritization here, since it seems the only users that the new behavior will make sense to are Mac users who use non-Firefox browsers.

Comment 14

[Daniel Holbert [:dholbert]]

(Also, note that over in bug 1187404, we *did* change the e10s <select> to align with our old/non-e10s behavior w.r.t. pressing "tab" after you've used the keyboard to choose an option. It seems a odd/inconsistent that "tab" now accepts the user's choice, whereas click-outside-the-menu discards it.)

Comment 15

[Daniel Holbert [:dholbert]]

[I think this belongs in Core|Widget (which is where <select> implementation lives), rather than in Firefox:Keyboard Navigation. Updating component & clarifying bug summary.]

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Neil Deakin from comment #8)
> Note that the correct way to accept the change in comment 0 is to press
> Enter at step 4 not click outside the menu.

Personally, my instincts prevent me from hitting "enter" when filling out a form, since in many cases (e.g. in Bugzilla's "Bug Summary" field, probably many other <input> fields), the "enter" key will simply submit the form right away.

Comment 17

[Neil Deakin]

This is a Linux-only bug.

There's no issue on Windows. On Windows, items in a dropdown are selected when the cursor keys are pressed, so clicking outside the popup will give the behaviour you are expecting. This is the same behaviour on Firefox with or without e10s, other browsers, and the system combobox behaviour.

On Mac and gtk, items are not selected until you close the popup, so clicking outside the popup cancels any keyboard navigation.

Can you clarify what issues you think exist on Windows?

Comment 18

[Daniel Holbert [:dholbert]]

Oh, sorry -- you're right, no issues on Windows. (I mistakenly assumed this behaved the same everywhere, and thought I remembered having tested on Windows, but I guess I didn't.)

Comment 19

[Daniel Holbert [:dholbert]]

(and that does essentially-negate my first bullet-point in comment 12, I suppose, RE benefits of matching win10 system behavior)

Comment 20

[Liviu Cirdei]

User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID 	20160209004008

This still reproduces on Aurora 46.0a2 and Nightly 47.0a1  -  Ubuntu 15.04.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Jim, do we have plans to work on this for 48? Or should we just wontfix it too.
Thanks

Comment 22

[Jim Mathies [:jimm]]

if someone picks it up we can uplift, but this is considered non-blocking.