Closed Bug 1296270 Opened 8 years ago Closed 7 years ago

e10s / non-e10s different mouse events behavior on <select> elements

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 1300784
Tracking Status
e10s + ---
firefox48 --- wontfix
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox53 --- wontfix

People

(Reporter: JuliaC, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

[Note]:
- This is a follow up issue filed for Bug 1291078.

[Affected versions]:
- 51.0a1 (2016-08-17)
- 50.0a2 (2016-08-18)
- 49.0b4 build1 (20160814184416)
- 48.0.1 build3 (20160817112116)

[Affected platforms]:
- Windows 10 x64
- Ubuntu 14.04 x86 
- Mac OS X 10.10.4

[Steps to reproduce]:
1. Launch Firefox.
2. Enable e10s (if it isn't already).
3. Open https://bug1291078.bmoattachments.org/attachment.cgi?id=8776788.
4. Click the right menu button in order to open the menu.
5. Click again the right menu button in order to close the menu.
- inspect the last fired events

[Expected result]:
- e10s and non-e10s behaviors correspond:  
 On step 5
 * mousedown
 * mouseup
 * click 
 are displayed (like in non-e10s case).

[Actual result]:
- on Windows, when e10s is on and on Ubuntu (e10s on/off), 
  * mouseup
  * click 
  are displayed;
- on Mac (e10s on/off), nothing is displayed.

[Regression range]:
- I will investigate this as soon as possible.
The menu opens (step 4) and closes (step 5) as expected. There is nothing user facing that is unexpected here.
Regression window(Win32 build on Windows10 x64):
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=dc24497dbda4&tochange=3e382ae494a8

Triggered by:3e382ae494a8	Mike Conley — Bug 1108761 - Make the parent process use a menulist popup for <select>'s in the content process. feedback=dao,r=Enn.
I don't think this is worth taking into a dot release. Wontfix for 48
(In reply to Sylvestre Ledru [:sylvestre] from comment #3)
> I don't think this is worth taking into a dot release. Wontfix for 48

I agree, this is an interesting find, but pretty minor, imo.
Are we going to try to fix this for >= 49, Mike? (Asking same question as in bug 1296264 just to keep these even more similar ;)
Flags: needinfo?(mconley)
Yes. jaws and I are mentoring some MSU students who are going to try to combine the e10s and non-e10s select dropdown implementations. I'll see if I can make this part of the stack of work there.
Flags: needinfo?(mconley)
See Also: → 1091592
Priority: -- → P2
See Also: 1091592
(In reply to Mike Conley (:mconley) from comment #7)
> Yes. jaws and I are mentoring some MSU students who are going to try to
> combine the e10s and non-e10s select dropdown implementations. I'll see if I
> can make this part of the stack of work there.

Were you able to do that, Mike?
Flags: needinfo?(mconley)
(In reply to Andrew Overholt [:overholt] from comment #8)
> (In reply to Mike Conley (:mconley) from comment #7)
> > Yes. jaws and I are mentoring some MSU students who are going to try to
> > combine the e10s and non-e10s select dropdown implementations. I'll see if I
> > can make this part of the stack of work there.
> 
> Were you able to do that, Mike?

The work is likely to land in 53 (bug 1300784), though disabled until we've had QA bang the tires a bit to make sure it works as expected.
Flags: needinfo?(mconley)
AFAIK, we have no intention of backporting bug 1300784 to Fx52, so calling this wontfix for that release.
Hi Mike, anything we need to do here? Or is this simply dupe. of bug 1300784?
Flags: needinfo?(mconley)
Yeah, let's dupe this over.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mconley)
Resolution: --- → DUPLICATE
Too late for a fix for 53, as we are in the last week of the 53 beta cycle.
You need to log in before you can comment on or make changes to this bug.