934123 - Select dropdown is misaligned when in a flex container

Status: VERIFIED FIXED

(Core :: Layout, defect, P4)

Description

[Daniel]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131030030201

Steps to reproduce:

* Visit http://telemetry.mozilla.org/#path=nightly/27/A11Y_CONSUMERS
* Click down arrow of the middle select element
* Try to scroll by dragging the scrollbar


Actual results:

* The dropdown is aligned to he left instead of to the select element itself (It's even more clear with the "reason*" dropdown)
* You can't drag the scrollbar

The issue is resolved by itself if you move the mouse back and forth over the edge of the dropdown...

Comment 1

[Manuela Muntean [Away]]

I can reproduce this with latest Aurora (build ID: 20131103004005) on Win 7 64-bit.

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #1

It appears to be caused by 'display:flex' on the "nav" element.

STR:
1. load the testcase
2. resize the window width
3. click on the select element

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: Testcase #2

Reduced the testcase a bit.

Comment 4

[Daniel Holbert [:dholbert]]

(As with the previous testcase, you generally have to resize the window to trigger this in testcase 2; though sometimes I hit it even without that.)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: fix v1

Looks like the issue is that we're failing to pass NS_FRAME_NO_MOVE_VIEW into FinishReflowChild.  So, when one of our "measuring" reflows calls FinishReflowChild with position 0,0 [1], the select frame ends up moving its popup's view to position 0,0.

We already pass NS_FRAME_NO_MOVE_FRAME to the actual ReflowChild calls (which includes the NO_MOVE_VIEW bit).  We should just ensure we pass that consistently to ReflowChild and FinishReflowChild.

This patch makes that consistent, and fixes the bug.

[1] (position 0,0 because we haven't finished resolving flexible lengths etc. yet, so we don't know where anything is)

Comment 6

[Daniel Holbert [:dholbert]]

https://tbpl.mozilla.org/?tree=Try&rev=4515eac20569

Comment 7

[Mats Palmgren (inactive)]

Comment on attachment 8349121 [details] [diff] [review]
fix v1

Seems reasonable.  r=mats

Comment 8

[Daniel Holbert [:dholbert]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/de950d66a584

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/de950d66a584

Comment 10

[Ioana (away)]

Daniel, could you please verify that this is fixed for you in Firefox 29?

Comment 11

[Daniel]

The issue is indeed resolved for me in Aurora 29.0a2 (2014-03-10).