Proposal to converge with Chromium / Blink for not firing events on <option>’s from <select> dropdowns

[Mike Conley]

Hey dev-platform,

TL;DR: I want Gecko to stop firing events on <option>’s on <select>
dropdowns.

Context:

Bug 1090602 was filed way back in the day by someone who used the old
Treestatus app, because they noticed it was broken once e10s was flipped on
by default. The problem was that the old Treestatus app was putting a click
event listener on a <select> to detect changes to the <select> and update
some state somewhere. With e10s (where the <select> dropdown is actually
opening in the parent), we weren’t triggering events on the selected
<option> in the content process.

So I’ve been hemming and hawing about how best to solve this, and I even
started working on the machinery to capture and synthesize the events from
the parent-side <xul:menulist>[1]. This ended up looking like a big pile of
work.

That’s when I found out that event behaviour for <option>’s is not spec’d
out, and the way in which events are fired differs widely from browser to
browser.

I tested Firefox Nightly (non-e10s), Safari, Chrome, Internet Explorer and
Edge, and posted my findings at [2].

What I’m proposing is that we try to converge with Chrome / Blink’s
behaviour on these events, where we do not fire any events on <option>’s,
ever, whenever e10s is enabled by default.

That’d greatly simplify my work in bug 1090602 - it’d basically be a
WONTFIX.

Note that this should not affect Gecko’s behaviour when the <select> is
displayed “inline” (for example, when the <select> has a “multiple”
attribute, or a “size” attribute with a value greater than 1). I'm only
concerned with the dropdown case.

Are there any objections or thoughts about this plan? Are there more events
that I've not considered in my manual test case[3] that I should test?

-Mike

[1]: Yep, that’s currently how we show the <select> dropdowns. We know
there are still usability problems with e10s’s <select> dropdowns, but this
email is not regarding those usability problems.
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1090602#c27
[3]: https://bug1090602.bmoattachments.org/attachment.cgi?id=8674454

[Anne van Kesteren]

On Thu, Oct 15, 2015 at 11:00 PM, Mike Conley <mco...@mozilla.com> wrote:
> Are there any objections or thoughts about this plan?

You should check what the HTML standard says and file an issue if it
doesn't match what you want browsers to do.


--
https://annevankesteren.nl/

[Mike Taylor]

Hi Mike,

On 10/15/15 4:00 PM, Mike Conley wrote:
> That’s when I found out that event behaviour for <option>’s is not spec’d
> out, and the way in which events are fired differs widely from browser to
> browser.
>
> I tested Firefox Nightly (non-e10s), Safari, Chrome, Internet Explorer and
> Edge, and posted my findings at [2].
>
> What I’m proposing is that we try to converge with Chrome / Blink’s
> behaviour on these events, where we do not fire any events on <option>’s,
> ever, whenever e10s is enabled by default.

<https://bugzilla.mozilla.org/show_bug.cgi?id=715990> seems relevant --
we don't fire click events on <option>s in Fennec either (because I
forgot to land the very first patch I wrote, lol?).

AFAIK, there has been no compat fallout from not supporting this.

--
Mike Taylor
Web Compat, Mozilla

[Ehsan Akhgari]

On 2015-10-15 5:00 PM, Mike Conley wrote:
> Note that this should not affect Gecko’s behaviour when the <select> is
> displayed “inline” (for example, when the <select> has a “multiple”
> attribute, or a “size” attribute with a value greater than 1). I'm only
> concerned with the dropdown case.

Why should the behavior be different with non-drop-down select elements?

[Mike Conley]

>> You should check what the HTML standard says and file an issue if it> doesn't match what you want browsers to do.

Unfortunately, the HTML standard doesn't say much with respect to what
events <option> elements are supposed to fire, and when.

Once we come to a conclusion here, perhaps I'll work with you to hammer
out that part of the spec.

[Mike Conley]

>> Why should the behavior be different with non-drop-down select elements?

The difference in behaviour is something that the other browsers _do_
seem to agree upon. When the <option> elements are inline (with the
multiple attribute, or size attribute set to > 1), it seems from my
testing that all browsers seem to fire events for mouseover, mousedown,
keyup, keydown, etc.

It's only the dropdown case that seems to be special for each browser -
likely due to the fact that the spec is vague for that case.

[Justin Dolske]

It makes sense to me because in the drop-down case, the user is
interacting with chrome UI (as opposed to something actually in
content). Same thing with context menus, autocomplete dropdowns, etc.

I think that in such cases, it would be ideal to only expose the final
result of the user's actions.

Justin

[Ehsan Akhgari]

On 2015-10-16 12:16 PM, Justin Dolske wrote:
> On 10/16/15 7:20 AM, Ehsan Akhgari wrote:
>> On 2015-10-15 5:00 PM, Mike Conley wrote:
>>> Note that this should not affect Gecko’s behaviour when the <select> is
>>> displayed “inline” (for example, when the <select> has a “multiple”
>>> attribute, or a “size” attribute with a value greater than 1). I'm only
>>> concerned with the dropdown case.
>>
>> Why should the behavior be different with non-drop-down select elements?
>
> It makes sense to me because in the drop-down case, the user is
> interacting with chrome UI (as opposed to something actually in
> content). Same thing with context menus, autocomplete dropdowns, etc.

That sounds like justifying a specific behavior to me. Here is the
counter argument:

The author has a <select size=5> in their app. They are relying on
receiving the events on the option elements. Then they add a
mySel.removeAttribute("size") call and suddenly their event handlers
stop working?!

That makes no sense to me!

[Mike Conley]

>> That makes no sense to me!

It might make no sense, but it's what Chromium has been shipping for (at
least) the last while. Not saying it's right, just saying that's where
it is.

I've updated my testcase[1] to demonstrate. There is now a click event
handler on the "Friday" <option>, and the <select> defaults to showing
inline <option>'s.

In Chrome, click Friday. Then toggle the "inline select" checkbox, and
then choose Friday from the dropdown. You'll only see the event handler
fire in the first case.

I guess this is what happens when the spec is unclear. :/

The easy path forward on bug 1090602 is to follow Chrome's approach. The
harder path is to try to maintain what we currently do (and fire events
with the dropdown and without).

So what should we do? Who makes the decision on this?

[1]: https://bug1090602.bmoattachments.org/attachment.cgi?id=8674977

On 2015-10-16 12:56 PM, Ehsan Akhgari wrote:
> On 2015-10-16 12:16 PM, Justin Dolske wrote:

>> On 10/16/15 7:20 AM, Ehsan Akhgari wrote:
>>> On 2015-10-15 5:00 PM, Mike Conley wrote:
>>>> Note that this should not affect Gecko’s behaviour when the <select> is
>>>> displayed “inline” (for example, when the <select> has a “multiple”
>>>> attribute, or a “size” attribute with a value greater than 1). I'm only
>>>> concerned with the dropdown case.
>>>
>>> Why should the behavior be different with non-drop-down select elements?
>>
>> It makes sense to me because in the drop-down case, the user is
>> interacting with chrome UI (as opposed to something actually in
>> content). Same thing with context menus, autocomplete dropdowns, etc.
>

> That sounds like justifying a specific behavior to me. Here is the
> counter argument:
>
> The author has a <select size=5> in their app. They are relying on
> receiving the events on the option elements. Then they add a
> mySel.removeAttribute("size") call and suddenly their event handlers
> stop working?!
>
> That makes no sense to me!
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform