1342925 - [e10s] overflow: auto on container hover causes issues when <select> dropdown is larger than container

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Barry Coughlan]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

http://jsfiddle.net/anxrdf59/1/

1. Open the select dropdown.
2. Move mouse to an option outside of the container (red box).


Actual results:

Two different results on different machines (both Firefox 51.0.1 32-bit on Windows 10 with all extensions disabled):

On one machine the dropdown closes and the selected option does not change. On another machine the dropdown closes but the selected option changes to the last option that was hovered over.


Expected results:

The dropdown should have stayed open (as in other browsers).

Comment 1

[Hani Yacoub, Desktop QA]

I tested this issue on different operating systems and here are the results:

- On Windows 10 x 64:
Firefox Nightly 54.0a1 - Not Reproducible
Firefox Nightly 53.0a1, 52.0a1 and 51.0a1- Reproducible

- On Ubuntu 16.04 x64:
Firefox Nightly 54.0a1, 53.0a1, 52.0a1 and 51.0a1 - Reproducible

- On Mac OS X 10.11: 
Firefox Nightly 54.0a1, 53.0a1, 52.0a1 and 51.0a1 - Reproducible

Comment 2

[Mats Palmgren (inactive)]

I'm guessing the 'overflow' style change leads to reframing the <select>.
Perhaps e10s doesn't restore the frame state like we do in the non-e10s case?

Comment 3

[Julien Cristau [:jcristau] (back April 22)]

Too late for firefox 52, mass-wontfix.

Comment 4

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

Looks like this is part of ongoing cleanup for problems with <select>.
Mats, can you (or maybe Jet) help find an owner for this issue?

Comment 5

[Mats Palmgren (inactive)]

I think @mconley @enndeakin and @jaws knows the e10s <select> code.

Comment 6

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

I can't tell if this should be a priority for anyone, or if we should drop it from ongoing regression triage. mconley, jaws, what do you think?

Comment 7

[Neil Deakin]

(In reply to Mats Palmgren (:mats) from comment #2)
> I'm guessing the 'overflow' style change leads to reframing the <select>.
> Perhaps e10s doesn't restore the frame state like we do in the non-e10s case?

So the same underlying issue as 1305017.

Comment 8

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

I agree - this is a dupe of bug 1305017.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #6)
> I can't tell if this should be a priority for anyone, or if we should drop
> it from ongoing regression triage. mconley, jaws, what do you think?

I don't think this is going to be a priority unless someone gets free'd up from Photon / Quantum work.

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Agree with comment #8.

Comment 10

[Jet Villegas (inactive)]

I'd love to see this fixed as part of the work in bug 1421229. Marking that dependency so we get this cleaned up. 

Tommy: can you add this as a test case when we finally render the menus in the content process? Thx!

Comment 11

[Tommy Kuo (away forever...)]

(In reply to Jet Villegas (:jet) from comment #10)
> I'd love to see this fixed as part of the work in bug 1421229. Marking that
> dependency so we get this cleaned up. 
> 
> Tommy: can you add this as a test case when we finally render the menus in
> the content process? Thx!

Ok, I'll put it on my test case list.