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

VERIFIED FIXED in Firefox 48

Status

()

Core
DOM: Core & HTML
VERIFIED FIXED
a year ago
7 months ago

People

(Reporter: neil, Assigned: mconley)

Tracking

({regression, site-compat})

48 Branch
mozilla51
regression, site-compat
Points:
---

Firefox Tracking Flags

(e10s?, firefox48+ verified, firefox49+ verified, firefox50+ verified, firefox51+ verified, relnote-firefox 48+)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(11 attachments, 2 obsolete attachments)

1.15 KB, text/html
Details
58 bytes, text/x-review-board-request
Neil Deakin (not available until Aug 9)
: review+
Details | Review
7.05 KB, patch
mrbkap
: review+
Neil Deakin (not available until Aug 9)
: review+
Details | Diff | Splinter Review
3.07 KB, patch
Neil Deakin (not available until Aug 9)
: review+
Details | Diff | Splinter Review
5.05 KB, patch
Neil Deakin (not available until Aug 9)
: review+
Details | Diff | Splinter Review
7.05 KB, patch
mconley
: review+
Details | Diff | Splinter Review
3.10 KB, patch
mconley
: review+
Details | Diff | Splinter Review
4.36 KB, patch
mconley
: review+
Details | Diff | Splinter Review
5.06 KB, patch
mconley
: review+
Details | Diff | Splinter Review
3.07 KB, patch
mconley
: review+
Details | Diff | Splinter Review
7.05 KB, patch
mconley
: review+
Details | Diff | Splinter Review
(Reporter)

Description

a year ago
Created attachment 8776788 [details]
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!
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
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
Product: Firefox → Core
See Also: → bug 1266575
Summary: <select> change event now fired before mouse events → <select> change event is fired before mouse events if e10s is enabled
This is quite bad regression to fire change events too early.
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
tracking-firefox48: --- → ?
tracking-firefox49: --- → ?
tracking-firefox50: --- → ?
tracking-firefox51: --- → ?
Keywords: regression
tracking-e10s: --- → ?
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.
Flags: needinfo?(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?
Flags: needinfo?(mconley) → needinfo?(bugs)
(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.
(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?
Flags: needinfo?(bugs)
(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".
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?
(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.
Created attachment 8777051 [details]
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/
Attachment #8777051 - Flags: review?(enndeakin)
Mike, looks you are working on this, I am setting assignee to you. Feel free to reset if I get something wrong.
Assignee: nobody → mconley
(Reporter)

Comment 12

a year ago
> 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.
Version: 49 Branch → 48 Branch
Mike, Olli: do you think this should be fixed in a 48 dot release before we push e10s to more users?
Flags: needinfo?(mconley)
Flags: needinfo?(bugs)
Restrict Comments: true
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.
Flags: needinfo?(bugs)
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/
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.
Flags: needinfo?(mconley)
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.
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 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/
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?
Flags: needinfo?(enndeakin)
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
Attachment #8777051 - Flags: review?(enndeakin) → review+
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.
Flags: needinfo?(enndeakin)
Okay, I think I can extract a safe amount of things from these patches. I'll have something up this afternoon.
Created attachment 8777447 [details] [diff] [review]
[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
Created attachment 8777448 [details] [diff] [review]
[For Release] Have SelectContentHelper dispatch events on <option> instead of <select>

MozReview-Commit-ID: 98oLdrutvAC
Attachment #8777447 - Attachment is obsolete: true
Attachment #8777447 - Attachment is obsolete: false
Created attachment 8777449 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: kYCFS51pvG
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.
Attachment #8777447 - Flags: review?(mrbkap)
Attachment #8777447 - Flags: review?(enndeakin)
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.
Attachment #8777448 - Flags: review?(enndeakin)
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.
Attachment #8777449 - Flags: review?(enndeakin)
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).
Attachment #8777447 - Flags: review?(enndeakin) → review+
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.
Attachment #8777449 - Flags: review?(enndeakin) → review+
Attachment #8777448 - Flags: review?(enndeakin) → review+
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.
Attachment #8777447 - Flags: approval-mozilla-release?
Comment on attachment 8777448 [details] [diff] [review]
[For Release] Have SelectContentHelper dispatch events on <option> instead of <select>

See comment 32.
Attachment #8777448 - Flags: approval-mozilla-release?
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.
Attachment #8777449 - Flags: approval-mozilla-beta?
Attachment #8777447 - Flags: review?(mrbkap) → review+
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.
Attachment #8777449 - Flags: review+
Attachment #8777449 - Flags: approval-mozilla-beta?
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/
Created attachment 8777504 [details] [diff] [review]
[For Release] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: kYCFS51pvG
Attachment #8777449 - Attachment is obsolete: true
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.
Attachment #8777504 - Flags: review?(enndeakin)
Attachment #8777504 - Flags: review?(enndeakin) → review+
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.
Attachment #8777504 - Flags: approval-mozilla-release?

Comment 40

a year ago
Pushed by mconley@mozilla.com:
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

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/62a983c56050
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox51: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Tracking 51+ for this e10s regression.
tracking-firefox51: ? → +
Keywords: site-compat
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.
Attachment #8777504 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #8777448 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #8777447 - Flags: approval-mozilla-release? → approval-mozilla-release+
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?
Flags: needinfo?(sledru)
The sheriff should do it
Flags: needinfo?(wkocher)
Flags: needinfo?(sledru)
Flags: needinfo?(cbook)
Created attachment 8778961 [details] [diff] [review]
[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
Created attachment 8778962 [details] [diff] [review]
[Aurora] Have SelectContentHelper dispatch events on <option> instead of <select>

MozReview-Commit-ID: 7dxVipFqhiV
Created attachment 8778963 [details] [diff] [review]
[Aurora] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: HvekgOrNoNA
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b21aba1ea758
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c5c99e5b9e93
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e853545b8093
Sorry, my work day got away from me with other tasks. Tomcat should be able to get these landed.
Flags: needinfo?(wkocher)
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
Flags: needinfo?(cbook)
btw mconley i guess you want this also on beta
status-firefox48: affected → fixed
Created attachment 8779334 [details] [diff] [review]
[Aurora] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: HvekgOrNoNA
Attachment #8778963 - Attachment is obsolete: true
Created attachment 8779359 [details] [diff] [review]
[Beta] Re-arrange events fired on <option> elements for e10s to match non-e10s

MozReview-Commit-ID: HvekgOrNoNA
Created attachment 8779360 [details] [diff] [review]
[Beta] Have SelectContentHelper dispatch events on <option> instead of <select>

MozReview-Commit-ID: 7dxVipFqhiV
Created attachment 8779361 [details] [diff] [review]
[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 on attachment 8778961 [details] [diff] [review]
[Aurora] Expose ChromeOnly openInParentProcess property on <select> elements

Rebased for Aurora.

Approval Request Comment: See comment 32.
Attachment #8778961 - Flags: review+
Attachment #8778961 - Flags: approval-mozilla-aurora?
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.
Attachment #8778962 - Flags: review+
Attachment #8778962 - Flags: approval-mozilla-aurora?
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.
Attachment #8779334 - Flags: review+
Attachment #8779334 - Flags: approval-mozilla-aurora?
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.
Attachment #8779359 - Flags: review+
Attachment #8779359 - Flags: approval-mozilla-beta?
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.
Attachment #8779360 - Flags: review+
Attachment #8779360 - Flags: approval-mozilla-beta?
Comment on attachment 8779361 [details] [diff] [review]
[Beta] Expose ChromeOnly openInParentProcess property on <select> elements

Rebased for Beta.

Approval Request Comment: See comment 32.
Attachment #8779361 - Flags: review+
Attachment #8779361 - Flags: approval-mozilla-beta?
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.
Flags: needinfo?(andrei.vaida)
Attachment #8779361 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8779360 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8779359 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8779334 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8778962 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8778961 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 66

a year ago
bugherderuplift
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
status-firefox50: affected → fixed

Comment 67

a year ago
bugherderuplift
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
status-firefox49: affected → fixed
Belatedly tracking for 49+ in case this reopens.
tracking-firefox48: ? → -
tracking-firefox49: ? → +
tracking-firefox50: ? → +
Flags: qe-verify+
(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?
Flags: needinfo?(andrei.vaida) → needinfo?(lhenry)
I am sure it is a typo! Fixing it!
tracking-firefox48: - → +
Flags: needinfo?(lhenry)
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.
Flags: needinfo?(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!
Flags: needinfo?(mconley)
(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?
Flags: needinfo?(mconley)

Comment 74

11 months ago
Added in the 48.0.1 release notes: "Fix a different behavior with e10s / non-e10s on <select> and mouse events".
relnote-firefox: --- → 48+
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.
Status: RESOLVED → VERIFIED
status-firefox48: fixed → verified
status-firefox49: fixed → verified
status-firefox50: fixed → verified
status-firefox51: fixed → verified
(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).
Flags: needinfo?(mconley)
(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.
Flags: qe-verify+
Blocks: 1266575
You need to log in before you can comment on or make changes to this bug.