Open Bug 1195200 Opened 5 years ago Updated 3 years ago

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

Categories

(Core :: Widget, defect, P3)

Unspecified
Linux
defect

Tracking

()

REOPENED
Tracking Status
e10s + ---
firefox40 --- unaffected
firefox41 --- disabled
firefox42 --- disabled
firefox43 - wontfix
firefox44 + wontfix
firefox45 + wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- fix-optional

People

(Reporter: Sylvestre, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: tpi:+)

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
And I had this issue before the switch to GTK3.
OS: Unspecified → Linux
tracking-e10s: --- → ?
Summary: Shortcut behavior changed → [e10s] Pull down menu: Keyboard selection behavior changed
I have this issue in Fx41 as well (non-GTK3, e10s).
The e10s version of <select> matches the OS behavior I see on Linux. The non-e10s version of <select> does not.
based on comment 3, please reopen if you disagree.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
[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).
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: WONTFIX → ---
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.
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.
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.
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!
Flags: needinfo?(jmathies)
(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.
Flags: needinfo?(jmathies)
Thanks Jim! Setting this to wontfix for 44. Please update status if the fix is ready for uplift to Beta44.
(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.
Duplicate of this bug: 1236072
(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.)
See Also: → 1187404
[I think this belongs in Core|Widget (which is where <select> implementation lives), rather than in Firefox:Keyboard Navigation. Updating component & clarifying bug summary.]
Component: Keyboard Navigation → Widget
Product: Firefox → Core
Summary: [e10s] Pull down menu: Keyboard selection behavior changed → [e10s] <select> pull down menu ignores selections made w/ keyboard, if user clicks outside of menu
(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.
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?
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.)
(and that does essentially-negate my first bullet-point in comment 12, I suppose, RE benefits of matching win10 system behavior)
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.
Priority: -- → P2
Jim, do we have plans to work on this for 48? Or should we just wontfix it too.
Thanks
Flags: needinfo?(jmathies)
if someone picks it up we can uplift, but this is considered non-blocking.
Flags: needinfo?(jmathies)
Whiteboard: tpi:+
Priority: P2 → P3
Blocks: e10s-select-event
No longer blocks: e10s-select
You need to log in before you can comment on or make changes to this bug.