Resolve behavioral differences between e10s and non-e10s <select> widgets

RESOLVED DUPLICATE of bug 1154677

Status

()

enhancement
RESOLVED DUPLICATE of bug 1154677
2 years ago
2 years ago

People

(Reporter: squib, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox55 affected)

Details

There are some behavioral differences in our e10s and non-e10s <select> implementations that are causing test failures when we enable the e10s version in non-e10s (see bug 1331725). We should resolve these. Below is a list of all the differences I've been able to find:

1) In non-e10s, hovering over a different options (or selecting it via the keyboard arrows) and hitting alt-down/up or esc confirms the selection. In e10s, it reverts the selection.

(Windows follows the e10s behavior for hovering and the non-e10s behavior for selecting via keyboard. GNOME follows e10s behavior.)

2) Left and right arrows navigate up/down in non-e10s, do nothing in e10s.

(Windows follows non-e10s behavior. GNOME follows e10s behavior.)

3) Setting `writing-mode: vertical-(lr|rl);` works on non-e10s, has no effect on e10s.

4) Key events on an open <select> popup are fired in non-e10s, but not fired in e10s.

(Chrome follows e10s behavior.)

... There are probably others!

We should figure out what behavior we'd like for all of these and update our e10s implementation (and/or the tests) accordingly.
(In reply to Jim Porter (:squib) from comment #0)
> 3) Setting `writing-mode: vertical-(lr|rl);` works on non-e10s, has no
> effect on e10s.

To clarify, the style has no effect on the *popup* in e10s. It styles the main <select> box fine.
It seems you can register for and receive mouse events on <option> elements in non-e10s; no mouse events fire in e10s. The e10s behavior is consistent with Chrome FWIW.
Flagging needinfo for Neil regarding issues: 1, 2, 4, and the issue in comment #2.

Issue #3
--------
According to https://www.w3.org/TR/css-writing-modes-3/#example-18096584 our e10s behavior is strictly a bug. This can probably be fixed easily by following what is done for gathering the computed styles of options and selects and forwarding it to the parent process. Please file a separate bug for this.
Flags: needinfo?(enndeakin)
> 4) Key events on an open <select> popup are fired in non-e10s, but not fired
> in e10s.

If I understand right, this is by design see bug 1119074
(In reply to Sam Foster [:sfoster] from comment #4)
> > 4) Key events on an open <select> popup are fired in non-e10s, but not fired
> > in e10s.
> 
> If I understand right, this is by design see bug 1119074

This is also tracked and discussed in bug 1300483
> According to https://www.w3.org/TR/css-writing-modes-3/#example-18096584 our
> e10s behavior is strictly a bug. This can probably be fixed easily by
> following what is done for gathering the computed styles of options and
> selects and forwarding it to the parent process. Please file a separate bug
> for this.

I filed bug 1349984 to track this.
(In reply to Sam Foster [:sfoster] from comment #4)
> > 4) Key events on an open <select> popup are fired in non-e10s, but not fired
> > in e10s.
> 
> If I understand right, this is by design see bug 1119074

Well, I think the intention of that bug is simply to stop events generated in browser chrome from getting passed to content (e.g. right-click on the tab bar and hit a key), not to stop events generated in content (e.g. open a <select> menu in the page and hit a key). It might be ok to just follow Chrome here, but our non-e10s behavior might be better for web devs. Instinctively, I'd say that we should make keypress events on <select> work the same as for <input type="text">.
Adding deps (I'd add bug 1300483 too but that makes a circular dep).
Depends on: 1349984
(In reply to Jim Porter (:squib) from comment #0)
> There are some behavioral differences in our e10s and non-e10s <select>
> implementations that are causing test failures when we enable the e10s
> version in non-e10s (see bug 1331725). We should resolve these. Below is a
> list of all the differences I've been able to find:
> 
> 1) In non-e10s, hovering over a different options (or selecting it via the
> keyboard arrows) and hitting alt-down/up or esc confirms the selection. In
> e10s, it reverts the selection.

This is slighly vague as to what you mean, but the e10s behaviour matches the correct system behaviour and the non-e10s behaviour does not.


> 2) Left and right arrows navigate up/down in non-e10s, do nothing in e10s.

There is already a bug for this which I cannot find currently.

> 3) Setting `writing-mode: vertical-(lr|rl);` works on non-e10s, has no
> effect on e10s.
> 
This is bug 1170129.
Flags: needinfo?(enndeakin)
Depends on: 1170129
No longer depends on: 1349984
Depends on: 1324560
The left/right keys issue is bug 1321810.
This is really a dupe of bug 1154677. Let's just track stuff there.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: e10s-select
You need to log in before you can comment on or make changes to this bug.