Open Bug 1137328 Opened 10 years ago Updated 3 years ago

Select menu closes with flexbox when removing an absolutely positioned element

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
36 Branch
Platform:
x86
macOS
Type:
defect

Tracking

()

People

(Reporter: scott.gonzalez, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

Attachments

(1 file)

Testcase without the mouseleave showing the same behavior
1.10 KB, text/html
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 Steps to reproduce: Apply `display: flex` to the body, append an element to the body on mouseover of a select and attach any handler to mouseleave event of the select. http://dev-test.nemikor.com/bugs/firefox/select-closes-with-flexbox.html Actual results: The option list closes as soon as you hover over the list (when mouseleave is triggered for the select). Expected results: The option list should stay open.
So what happens here is that every time the mouse moves to a different <option> the page removes and reinserts the "other" element. I bet that causes frame reconstruction due to flexbox frame fixups.
Component: Untriaged → Layout
Product: Firefox → Core
I wonder whether we can just persist the "opened" state of the combobox somehow across frame reconstructs like this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Select menu closes on hover with flexbox and mouseleave event handler → Select menu closes on hover with flexbox and mousemove event handler that modifies the DOM
(In reply to Not doing reviews right now from comment #1) > I bet that causes frame reconstruction due to flexbox frame fixups. Right, likely because "#other-element" is absolutely positioned, which makes it drop an (inline-level) placeholder, which we wrap with an anonymous flex item (though that'll change in bug 874718). I expect you should be able to trigger the same issue by just appending a text node to the <body> (the flex container) as well. To fix this, we'd need to handle tweaks that involve anonymous flex items (i.e. tweaks w/ text nodes that are direct children of a flex container) *without* doing frame reconstruction on the other flex items. Not sure offhand how tricky that is. (Or maybe there's a way of persisting opened-ness across a frame-reconstruct, per comment 3; not sure)
There's another issue at play here, which is what's causing the DOM to be modified at all in the original page this bug is about. When moving from a combobox to its dropdown, we fire mouseleave on the combobox (with relatedTarget being the root element?). So in the original page that causes removal of the abs pos thing from the DOM, and hence frame reconstruction bits. The fact that we mouseleave the <select> when hovering its dropdown seems odd.
As far as the frame construction bits, could we avoid reconstructing the flex container if all we're trying to do is remove an anonymous flex item? That won't necessarily help with _adding_ anon flex items, of course.
Summary: Select menu closes on hover with flexbox and mousemove event handler that modifies the DOM → Select menu closes with flexbox when removing an absolutely positioned element
I've updated the title to more accurately explain what happens. I've also updated the test case.
> When moving from a combobox to its dropdown, we fire mouseleave on the combobox And then immediately fire mouseenter, afaict. That's just dumb.
That last may be bug 423719, fwiw.
Depends on: 423719
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: