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

RESOLVED DUPLICATE of bug 1300784

Status

()

defect
P2
normal
RESOLVED DUPLICATE of bug 1300784
3 years ago
2 years ago

People

(Reporter: JuliaC, Unassigned)

Tracking

(Blocks 1 bug, {regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+, firefox48 wontfix, firefox49 wontfix, firefox50 wontfix, firefox51 wontfix, firefox52 wontfix, firefox53 wontfix)

Details

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

Comment 2

3 years ago
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
Comment hidden (obsolete)
(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
Last Resolved: 2 years ago
Flags: needinfo?(mconley)
Resolution: --- → DUPLICATE
Duplicate of bug: 1300784
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.