1291078 - <select> change event is fired before mouse events if e10s is enabled

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[neil]

Attachment: eventsorder.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

The order of some events has changed between Firefox stable (47.0) and the latest alpha on 49 branch. Steps to reproduce (test case attached):

1. Add mousedown/up + click + change events to a <select>
2. Click on the <select> to open the menu, then click an option to select it.


Actual results:

(In Firefox v49 alpha)

On click to open the menu:
* mousedown
* mouseup
* click

Then on click to select an option:
* change
* mousedown
* mouseup
* click


Expected results:

In Firefox stable (v47), you get the following:

On click to open the menu:
* mousedown
* mouseup
* click

Then on click to select an option:
* mousedown
* mouseup
* change
* click

Note the change event is *after* the mouse events. I'm not sure if this new behaviour is intentional or not. The behaviour is different again in Safari:

On click to open the menu:
* mousedown

Then on click to select an option:
* change
* mouseup
* click

And in Chrome:

On click to open the menu:
* mousedown

Then on click to select an option:
* mouseup
* click
* change

So… it's a bit of a mess (all tests on a Mac). Our app (FastMail) currently presumes in one part of the UI that the change event will not be followed by a mousedown event (a popover is opened on change, which automatically closes if you click outside of it; the change in behaviour causes it to immediately detect a click outside). We can work around it, but I want to check this change is intentional first!

Comment 1

[Tooru Fujisawa [:arai]]

This issue is e10s only.

The "click", "mousedown", "mouseup" events on click are added by the patch for bug 1266575.
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3e069aea556fa27693c7ea0660f98107148143af&tochange=d2bd7cfc6d8c0aaf1dab44de0e6b8ad5aff13f4f

but the dispatch order is different between non-e10s and e10s.

non-e10s:
  On click to open the menu:
    * mousedown
    * mouseup
    * click

  Then on click to select an option:
    * mousedown
    * mouseup
    * change
    * click

e10s:
  On click to open the menu:
    * mousedown
    * mouseup
    * click

  Then on click to select an option:
    * change
    * mousedown
    * mouseup
    * click

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

This is quite bad regression to fire change events too early.

Comment 3

[Neil Deakin]

Bug 1289528 makes the mouse events fire on the right element which might improve things but not all. Maybe we should at least fire the events in the same order as non-e10s. But lets ask mconley if this was intentional.

In general though, the sending of mouse events on option elements is undefined and each browser and each platform does different things and you shouldn't write code that relies on it.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

(In reply to Neil Deakin from comment #3)
> Bug 1289528 makes the mouse events fire on the right element which might
> improve things but not all. Maybe we should at least fire the events in the
> same order as non-e10s. But lets ask mconley if this was intentional.

It was intentional in that we were aware that the spec is super unclear about when events should be fired for <select>'s. Bug 1266575 kinda illustrates this.

> In general though, the sending of mouse events on option elements is
> undefined and each browser and each platform does different things and you
> shouldn't write code that relies on it.

Agreed.

I wonder if the safest solution would be to attempt to mimic what we did with non-e10s, now that we can properly dispatch events onto the <option> elements themselves.

smaug, does that sound acceptable?

Comment 5

[Mike Conley (:mconley) (:⚙️)]

(In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #4)
> I wonder if the safest solution would be to attempt to mimic what we did
> with non-e10s, now that we can properly dispatch events onto the <option>
> elements themselves.

Note that I think doing this would require us to uplift Enn's patches from bug 1289528.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #4)
> I wonder if the safest solution would be to attempt to mimic what we did
> with non-e10s, now that we can properly dispatch events onto the <option>
> elements themselves.
> 
> smaug, does that sound acceptable?

I'm missing something here. What did we do with non-e10s?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

(In reply to Olli Pettay [:smaug] from comment #6)
> (In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #4)
> > I wonder if the safest solution would be to attempt to mimic what we did
> > with non-e10s, now that we can properly dispatch events onto the <option>
> > elements themselves.
> > 
> > smaug, does that sound acceptable?
> 
> I'm missing something here. What did we do with non-e10s?

Sorry, typo, "mimic what we did with non-e10s", should have been "mimic what we do with non-e10s".

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

So where do we currently dispatch the change event in e10s case? Could we just move mouse event dispatching to happen earlier and trigger the 'change' firing code path right before 'click' dispatch?

Comment 9

[Mike Conley (:mconley) (:⚙️)]

(In reply to Olli Pettay [:smaug] from comment #8)
> So where do we currently dispatch the change event in e10s case? Could we
> just move mouse event dispatching to happen earlier and trigger the 'change'
> firing code path right before 'click' dispatch?

Yep, that's what I'm proposing here. I'll post a patch.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1291078 - More closely mimic non-e10s order of events when choosing <select> elements in e10s mode.

Review commit: https://reviewboard.mozilla.org/r/68652/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/68652/

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Mike, looks you are working on this, I am setting assignee to you. Feel free to reset if I get something wrong.

Comment 12

[neil]

> In general though, the sending of mouse events on option elements is
> undefined and each browser and each platform does different things
> and you shouldn't write code that relies on it.

In general, yes I agree. The specific ordering change that causes the problem in our app is the "change" event occurring before the "mousedown" event that triggered it. Although undefined, and so I guess allowable, this is intuitively wrong.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Mike, Olli: do you think this should be fixed in a 48 dot release before we push e10s to more users?

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

This is at the edge. I think, given that this already broke a site, we should fix this in a dot release.

Btw, the patch doesn't fix 'input' event which has similar issue:
compare 
data:Text/html,<select onmousedown="console.log(event);"  onmouseup="console.log(event);"  onclick="console.log(event);"  onchange="console.log(event);"  oninput="console.log(event);"><option>1</option><option>2</option></select>

in e10s and non-e10s.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777051 [details]
Bug 1291078 - More closely mimic non-e10s order of events when choosing <select> elements in e10s mode.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/68652/diff/1-2/

Comment 16

[Mike Conley (:mconley) (:⚙️)]

I concur with smaug. If we have the time to get this into a point release, it's probably worth it.

Note that, if we're going to uplift this, we will also need to uplift the patches in bug 1289528, unless we're okay with the events being dispatched off of the <select> and not the <option> elements.

Comment 17

[Neil Deakin]

https://reviewboard.mozilla.org/r/68652/#review65998

::: toolkit/modules/SelectContentHelper.jsm:118
(Diff revision 2)
>          break;
>  
>        case "Forms:DismissedDropDown":
>          if (this.initialSelection != this.element.item(this.element.selectedIndex)) {
>            let win = this.element.ownerDocument.defaultView;
> +          // Going for mostly-Blink parity here, which (at least on Windows)

Or maybe Firefox non-e10s parity.

::: toolkit/modules/SelectContentHelper.jsm:131
(Diff revision 2)
> +              view: win,
> +              bubbles: true,
> +              cancelable: true,
> +            });
> +            this.element.dispatchEvent(mouseEvent);
> +            if (eventName == "mouseup") {

Might as well move the removeContentState outside the loop so the condition isn't needed.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

https://reviewboard.mozilla.org/r/68652/#review65998

> Or maybe Firefox non-e10s parity.

I'll just remove the first two lines from the comment - I don't think it actually adds much.

Comment 19

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777051 [details]
Bug 1291078 - More closely mimic non-e10s order of events when choosing <select> elements in e10s mode.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/68652/diff/2-3/

Comment 20

[Mike Conley (:mconley) (:⚙️)]

Hey Neil,

How safe do you think bug 1289528 is for uplift to a point release on the release channel? Or do you think we could get away with firing these events on the <select> event for now?

Comment 21

[Neil Deakin]

Comment on attachment 8777051 [details]
Bug 1291078 - More closely mimic non-e10s order of events when choosing <select> elements in e10s mode.

https://reviewboard.mozilla.org/r/68652/#review66020

Comment 22

[Neil Deakin]

I do think that sending the events on the wrong element isn't good. It might be better not to send them at all.

The patch in 1289528 (you only need part 1) is also dependent on 1194027 which is a bit less safe. Either accept that as well, or simplify the change to layout/forms/nsListControlFrame.cpp in bug 1289528 not to depend on it.

Comment 23

[Mike Conley (:mconley) (:⚙️)]

Okay, I think I can extract a safe amount of things from these patches. I'll have something up this afternoon.

Comment 24

[Mike Conley (:mconley) (:⚙️)]

Attachment: [For Release] Expose ChromeOnly openInParentProcess property on <select> elements

This is a simplified backport of some of the work done in bug 1194027.

MozReview-Commit-ID: 9M1M6gPWA8M

Comment 25

[Mike Conley (:mconley) (:⚙️)]

Attachment: [For Release] Have SelectContentHelper dispatch events on <option> instead of <select>

MozReview-Commit-ID: 98oLdrutvAC

Comment 26

[Mike Conley (:mconley) (:⚙️)]

Attachment: [For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: kYCFS51pvG

Comment 27

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777447 [details] [diff] [review]
[For Release] Expose ChromeOnly openInParentProcess property on <select> elements

Okay, I extracted out the part of bug 1194027 that I needed (the openInParentProcess property). Requesting review from mrbkap as well, since I'm updating a WebIDL, and I need a DOM peer.

Comment 28

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777448 [details] [diff] [review]
[For Release] Have SelectContentHelper dispatch events on <option> instead of <select>

This is a straight forward-port of the first patch in bug 1289528.

Comment 29

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777449 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

And this is a forward-port of the patch from this bug.

I realize now that on 48, we fire the input event for e10s, but we don't for non-e10s. I'm not sure if that's a problem. Also not completely sure if we need to keep the kStateActive removal as well. Hoping you can advise, Neil.

Comment 30

[Mike Conley (:mconley) (:⚙️)]

With these three patches on the release branch, the browser_selectpopup.js test passes, and my manual testing of the e10s-case shows us firing the events in the right order. Same with the non-e10s case, which I wouldn't have expected to have changed here, but I checked just to be sure (though we don't fire "input" in the non-e10s case).

Comment 31

[Neil Deakin]

Comment on attachment 8777449 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

The active flag clearing is a minor polish issue.

Comment 32

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777447 [details] [diff] [review]
[For Release] Expose ChromeOnly openInParentProcess property on <select> elements

Approval Request Comment
[Feature/regressing bug #]:

Bug 1266575

[User impact if declined]:

Sites that rely on the order of events on <select> or <option> elements will notice a different ordering between e10s and non-e10s. This has, apparently, broken at least one site.

[Describe test coverage new/current, TreeHerder]:

There are automated tests for the <select> events in the tree, which have been updated for the new ordering, and pass for me locally.

[Risks and why]: 

We're changing the behaviour of how select popups work for e10s. I think this is pretty safe, but we'll probably want QA to bang the tires on this (exercising select dropdowns with e10s enabled and disabled) to make sure we didn't miss anything.

[String/UUID change made/needed]:

None.

Comment 33

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777448 [details] [diff] [review]
[For Release] Have SelectContentHelper dispatch events on <option> instead of <select>

See comment 32.

Comment 34

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777449 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

See comment 32.

Comment 35

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777449 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

Bah - failed local automated testing. I got the event targets wrong.

Comment 36

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777051 [details]
Bug 1291078 - More closely mimic non-e10s order of events when choosing <select> elements in e10s mode.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/68652/diff/3-4/

Comment 37

[Mike Conley (:mconley) (:⚙️)]

Attachment: [For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: kYCFS51pvG

Comment 38

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777504 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

I had rearranged the event order, but I accidentally targeted the mouse events at the <select> and not the <option> elements.

I think one more glance might be worth it to make sure there's nothing else hiding in here.

Comment 39

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8777504 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

See comment 32.

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/62a983c56050
More closely mimic non-e10s order of events when choosing <select> elements in e10s mode. r=enndeakin+6102

Comment 41

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/62a983c56050

Comment 42

[Marcia Knous [:marcia]]

Tracking 51+ for this e10s regression.

Comment 43

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8777504 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

Let's try it to fix incompatibilities between our versions.

Comment 44

[Mike Conley (:mconley) (:⚙️)]

Hey Sylvestre - do you know if I need to land these on the release branch myself, or will a sheriff come along and do it?

Comment 45

[Sylvestre Ledru [:Sylvestre]]

The sheriff should do it

Comment 46

[Mike Conley (:mconley) (:⚙️)]

Attachment: [Aurora] Expose ChromeOnly openInParentProcess property on <select> elements

This is a simplified backport of some of the work done in bug 1194027.

MozReview-Commit-ID: 9M1M6gPWA8M

Comment 47

[Mike Conley (:mconley) (:⚙️)]

Attachment: [Aurora] Have SelectContentHelper dispatch events on <option> instead of <select>

MozReview-Commit-ID: 7dxVipFqhiV

Comment 48

[Mike Conley (:mconley) (:⚙️)]

Attachment: [Aurora] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: HvekgOrNoNA

Comment 49

[Mike Conley (:mconley) (:⚙️)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b21aba1ea758

Comment 50

[Mike Conley (:mconley) (:⚙️)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c5c99e5b9e93

Comment 51

[Mike Conley (:mconley) (:⚙️)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e853545b8093

Comment 52

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Sorry, my work day got away from me with other tasks. Tomcat should be able to get these landed.

Comment 53

[Carsten Book [:Tomcat]]

landed

remote:   https://hg.mozilla.org/releases/mozilla-release/rev/c8f17ac10df5
remote:   https://hg.mozilla.org/releases/mozilla-release/rev/f0b7fef514f4
remote:   https://hg.mozilla.org/releases/mozilla-release/rev/e7d4b84c0ced

Comment 54

[Carsten Book [:Tomcat]]

btw mconley i guess you want this also on beta

Comment 55

[Mike Conley (:mconley) (:⚙️)]

Attachment: [Aurora] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: HvekgOrNoNA

Comment 56

[Mike Conley (:mconley) (:⚙️)]

Attachment: [Beta] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: HvekgOrNoNA

Comment 57

[Mike Conley (:mconley) (:⚙️)]

Attachment: [Beta] Have SelectContentHelper dispatch events on <option> instead of <select>

MozReview-Commit-ID: 7dxVipFqhiV

Comment 58

[Mike Conley (:mconley) (:⚙️)]

Attachment: [Beta] Expose ChromeOnly openInParentProcess property on <select> elements

This is a simplified backport of some of the work done in bug 1194027.

MozReview-Commit-ID: 9M1M6gPWA8M

Comment 59

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8778961 [details] [diff] [review]
[Aurora] Expose ChromeOnly openInParentProcess property on <select> elements

Rebased for Aurora.

Approval Request Comment: See comment 32.

Comment 60

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8778962 [details] [diff] [review]
[Aurora] Have SelectContentHelper dispatch events on <option> instead of <select>

Rebased for Aurora.

Approval Request Comment: See comment 32.

Comment 61

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8779334 [details] [diff] [review]
[Aurora] Re-arrange events fired on <option> elements for e10s to match non-e10s

Rebased for Aurora.

Approval Request Comment: See comment 32.

Comment 62

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8779359 [details] [diff] [review]
[Beta] Re-arrange events fired on <option> elements for e10s to match non-e10s

Rebased for Beta.

Approval Request Comment: See comment 32.

Comment 63

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8779360 [details] [diff] [review]
[Beta] Have SelectContentHelper dispatch events on <option> instead of <select>

Rebased for Beta.

Approval Request Comment: See comment 32.

Comment 64

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8779361 [details] [diff] [review]
[Beta] Expose ChromeOnly openInParentProcess property on <select> elements

Rebased for Beta.

Approval Request Comment: See comment 32.

Comment 65

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

Comment on attachment 8779361 [details] [diff] [review]
[Beta] Expose ChromeOnly openInParentProcess property on <select> elements

Let's take all patches on aurora and beta as marked so we fix the select order on all channels.   

It may make sense for QA to do some testing with tinderbox builds on the release channel before we are even ready to do a release build. Andrei, what do you think? We would definitely need testing once we're closer to the dot release.

Comment 66

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d67e58e5ad8c
https://hg.mozilla.org/releases/mozilla-aurora/rev/cff9e0a1ca42
https://hg.mozilla.org/releases/mozilla-aurora/rev/fb956712e50f

Comment 67

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-beta/rev/ef550c3f5a77
https://hg.mozilla.org/releases/mozilla-beta/rev/989dd4e6803e
https://hg.mozilla.org/releases/mozilla-beta/rev/63cdaf45dd02

Comment 68

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

Belatedly tracking for 49+ in case this reopens.

Comment 69

[Andrei Vaida [:avaida]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #65)
> It may make sense for QA to do some testing with tinderbox builds on the
> release channel before we are even ready to do a release build. Andrei, what
> do you think? We would definitely need testing once we're closer to the dot
> release.

Sure, we can do that. I see this bug is no longer being tracked for 48, is it still going to be included in 48.0.1?

Comment 70

[Sylvestre Ledru [:Sylvestre]]

I am sure it is a typo! Fixing it!

Comment 71

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

Based on comment 0, comment 32 and comment 65, I reproduced this issue on 50.0a1 (2016-08-01) and also, I investigated it on: 
- 51.0a1 (2016-08-11)
- 50.0a2 (2016-08-11)
- 49.0b3 build1 (20160811031722)
- 48.0.1 (20160811095921) (tinderbox-build)
using 
- Windows 10 x64
- Ubuntu 14.04 x86 
- Mac OS X 10.10.4.

These are the results:
- on all platforms, when clicking the same option (previously selected) from the menu in order to select it again, there are 2 cases:
  1. when e10s is on, nothing is displayed;
  2. when e10s is off,
  * mousedown
  * mouseup
  * click 
  are displayed;
- when clicking the right menu button in order to close the menu, there are 3 cases:
  1. on Windows, when e10s is on and on Ubuntu (e10s on/off), 
  * mouseup
  * click 
  are displayed;
  2. on Windows, when when e10s is off, 
  * mousedown
  * mouseup
  * click 
  are displayed;
  3. on Mac, nothing is displayed.

Can you please confirm if these are expected? 

Also, clicking the right menu button in order to open the menu and clicking an option (not previously selected) from the menu in order to select it have the expected results.

If there are another items that require testing for this issue, please let me know.

Comment 72

[Mike Conley (:mconley) (:⚙️)]

(In reply to Iulia Cristescu, QA [:IuliaC] from comment #71)
> These are the results:
> - on all platforms, when clicking the same option (previously selected) from
> the menu in order to select it again, there are 2 cases:
>   1. when e10s is on, nothing is displayed;
>   2. when e10s is off,
>   * mousedown
>   * mouseup
>   * click 
>   are displayed;

That sounds like a separate bug, but it also doesn't sound too bad. Can you please file?

> - when clicking the right menu button in order to close the menu, there are
> 3 cases:
>   1. on Windows, when e10s is on and on Ubuntu (e10s on/off), 
>   * mouseup
>   * click 
>   are displayed;
>   2. on Windows, when when e10s is off, 
>   * mousedown
>   * mouseup
>   * click 
>   are displayed;
>   3. on Mac, nothing is displayed.
> 
> Can you please confirm if these are expected? 
> 
> Also, clicking the right menu button in order to open the menu and clicking
> an option (not previously selected) from the menu in order to select it have
> the expected results.
> 

That also sounds like a separate bug. Would you mind filing that as well please?

Thanks!

Comment 73

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

(In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #72)

> That sounds like a separate bug, but it also doesn't sound too bad. Can you
> please file?
> 

> 
> That also sounds like a separate bug. Would you mind filing that as well
> please?
> 

Thank you! 
It is just one more detail to be clarified: what are the expected results in each of these two problematic cases?

Comment 74

[Gerry Chang [:gchang]]

Added in the 48.0.1 release notes: "Fix a different behavior with e10s / non-e10s on <select> and mouse events".

Comment 75

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

I verified again this issue on 48.0.1 build1 (20160816033124) across platforms. Based on comment 71 and comment 72, I will set the corresponding flags and mark this bug as Verified Fixed.

Comment 76

[Mike Conley (:mconley) (:⚙️)]

(In reply to Iulia Cristescu, QA [:IuliaC] from comment #73)
> (In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #72)
> 
> > That sounds like a separate bug, but it also doesn't sound too bad. Can you
> > please file?
> > 
> 
> > 
> > That also sounds like a separate bug. Would you mind filing that as well
> > please?
> > 
> 
> Thank you! 
> It is just one more detail to be clarified: what are the expected results in
> each of these two problematic cases?

Ideally, non-e10s and e10s should be a match (except for any "input" events, which non-e10s doesn't currently support, I don't think).

Comment 77

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

(In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #76)
> (In reply to Iulia Cristescu, QA [:IuliaC] from comment #73)
> > (In reply to Mike Conley (:mconley) - (Needinfo me!) from comment #72)
> > 
> > > That sounds like a separate bug, but it also doesn't sound too bad. Can you
> > > please file?
> > > 
> > 
> > > 
> > > That also sounds like a separate bug. Would you mind filing that as well
> > > please?
> > > 
> > 
> > Thank you! 
> > It is just one more detail to be clarified: what are the expected results in
> > each of these two problematic cases?
> 
> Ideally, non-e10s and e10s should be a match (except for any "input" events,
> which non-e10s doesn't currently support, I don't think).

Thank you! Filed Bug 1296264 and Bug 1296270.