1301118 - Adding an absolute-positioned element to a flexbox container triggers (expensive) flex relayout, even though it shouldn't affect other frames' positions

Status: NEW

(Core :: Layout, defect, P3)

Description

[trevorburnham]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce:

Add an absolute-positioned element with explicit `top` and `left` to a container with `display: flex` and take note of the impact on performance. Example: codepen.io/TrevorBurnham/pen/BLNWWy


Actual results:

The flexbox container recalculates its layout and re-renders, even though the new element has no possible effect on layout. This can be very expensive, as you can see in the CodePen above. (I ran into this problem in an app I was developing where the document body had `display: flex`. Appending a simple pop-up widget would cause the whole page to undergo layout, even if it had `position: fixed`.)


Expected results:

Appending such an element should not trigger layout/render.

Possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=874718.

Comment 1

[Daniel Holbert [:dholbert]]

Thanks for the bug! Indeed, once bug 874718 is closed out, we should be able to make the optimization that you're suggesting (no need to re-run flex layout if we're simply adding an abspos child, once we've got the new behavior where that abspos child doesn't influence the normal-flow children).

Some concrete STR here:
 1. Visit https://codepen.io/TrevorBurnham/pen/BLNWWy
 2. Open console (ctrl-shift-k)
 3. Compare the logged time durations for blockDiv/flexDiv.

EXPECTED RESULTS: durations should be similar.
ACTUAL RESULTS: flexDiv is an order of magnitude larger.  For me, the logged blockDiv value is in the 3-6 range, whereas the logged flexDiv value is in the 30-50 range.