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

Status: RESOLVED DUPLICATE of bug 1154677

(Core :: Layout: Form Controls, enhancement)

Description

[Jim Porter (:squib)]

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.

Comment 1

[Jim Porter (:squib)]

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

Comment 2

[Sam Foster [:sfoster] (he/him)]

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.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

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.

Comment 4

[Sam Foster [:sfoster] (he/him)]

> 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

Comment 5

[Sam Foster [:sfoster] (he/him)]

(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

Comment 6

[Sam Foster [:sfoster] (he/him)]

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

Comment 7

[Jim Porter (:squib)]

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

Comment 8

[Jim Porter (:squib)]

Adding deps (I'd add bug 1300483 too but that makes a circular dep).

Comment 9

[Neil Deakin]

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

Comment 10

[Neil Deakin]

The left/right keys issue is bug 1321810.

Comment 11

[Jim Porter (:squib)]

This is really a dupe of bug 1154677. Let's just track stuff there.