1163431 - Strange intermediate renderings and/or aggressive reflowing, when changing the height of an abspos child in a nested-flexbox scenario

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[batogovsky]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

Steps to reproduce:

I tried a lot to make a simple example, but only at bvsf.org i have repro.

When mouse hovers top menus - every thing start jump on page. Some times only after scrolling top-bottom, and when first menu is active.

It is only in Firefox, and when i add display:block to slide's inside slider with id "mainSlider" bug disappear(4 nodes in node with id "innerNode"). So it looks like problem is in flexbox.

I have stable repro on both linux and windows.


Actual results:

Firefox draw something strange, randomly jump elements with no reason.


Expected results:

Under menu white lines should appear and disappear.

Comment 1

[Daniel Holbert [:dholbert]]

Thanks for filing a bug! I tried to reproduce for a bit, but I couldn't reproduce what you described.

Could you provide more detailed steps to reproduce? (e.g. specific steps that reliably trigger the bug for you, if possible.) I don't see any change here when I hover the top menus, 

Also, it'd be helpful if you could provide a video of the bug in action, to make it clearer what's going on. (On Ubuntu Linux, the tool "gtk-recordmydesktop" is quite handy for recording screencasts.)

(Also, I'm un-checking the "security-sensitive" flag -- there doesn't seem to be anything security-related here. Randomly jumping does sound odd, but it's unlikely to be a security vulnerability.)

Comment 2

[batogovsky]

Please fix url to http://bvsf.org, we have no ssl certificate yet. Also i dont know how security flag have been chosen, it is mistakable.

I will record video soon, steps are simple - open site, hover top menu. May be it depends on hardware, maybe intel embedded graphic cards. In both cases intel embedded graphics used.

Comment 3

[batogovsky]

Here i shown that all is ok in chrome and the bug in firefox: https://www.youtube.com/watch?v=BzHbMdzslmQ

And here i shown that it depends on flexbox - i change display to block and bug disappear: https://www.youtube.com/watch?v=7zIyC0dx3c0

Comment 4

[Daniel Holbert [:dholbert]]

Thanks! Based on that video, this looks a bit like bug 894594 (and I think there are a few other similar bugs).

Basically:
 - our flexbox layout implementation involves some "measuring" stages, where we give an element a "dummy" height:auto, briefly, just to produce a measurement of its intrinsic height. Then we lay it out again with a "final" height.  The "dummy" intermediate layout isn't ever supposed to be painted onscreen.
 - BUT, we also have code that interrupts layout if it's taking too long, so that we can stay responsive to user input on complicated pages. (When this happens, we'll paint the current intermediate laid-out state, and then continue layout afterwards.)
 - So -- if a reflow that involves a flexbox is taking too long and gets interrupted, we may end up rendering an intermediate "dummy" state, with bogus sizing values.

Bug 894594 comment 10 has one solution for this -- preventing interrupts during these measurement stages.  I'm a bit mixed on that solution, though, because it'll mean we'll just hang instead of painting bogus-sized stuff, and I'm not sure that's better (depending on how long the hang is).

Comment 5

[batogovsky]

Okay, but why this measurements take place? My code change the element that positioned absolutely, it can not change anything on page layout. Is it another bug?

Comment 6

[batogovsky]

And from what you say it looks like here is infinit loop in size measurements. That in fact never stops. Because any dom changes triggers that jumping. It mean that dom engine start measurements and go in infinite loop, and then your logic break it. But measurements starts again when dom changed again.

I think it is much important bug.

Comment 7

[batogovsky]

Did you need this example? (bvsf.org)

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to batogovsky from comment #5)
> Okay, but why this measurements take place? My code change the element that
> positioned absolutely, it can not change anything on page layout.

I'm not entirely sure what's going on here, but there's likely some room for optimizing Gecko, when the size of an absolutely positioned child of a flex container is resized.  I think we may be reflowing the flex container greedily here. (Its child changed size, so we assume it may be changing size, too.)

Basically, the page has this nested structure:
   <topmenu>
     <btntopimage>
       [Some text her]
       <div id="underline">
     
And on hover, you transition the "height" property of the underline div.  This can impact the intrinsic size of the parent, except that its abspos (as you noted), which means it really won't.

(In reply to batogovsky from comment #7)
> Did you need this example? (bvsf.org)

(Not sure what you're asking here. You already provided the URL up above, so we've got that linked from this bug report already -- thanks!)

Comment 9

[Daniel Holbert [:dholbert]]

Note: I still haven't reproduced stuff jumping around, but I can see that we're reflowing aggressively when I hover this text, using a logging patch that I've got applied locally. (These reflows don't show up in the Browser Console logging for some reason, though.)

So, I've marked this as "NEW" (i.e. confirmed), and I'm adjusting the summary a bit to be a bit more specific.

Comment 10

[batogovsky]

I need to fix that site, it is in production. So i made copy for you: http://bvsf.org/bug/

Comment 11

[Daniel Holbert [:dholbert]]

Thanks!

I may not get to it right away, but I hope to be able to dig in more sometime in the next ~month.

(Bug 1150123 comment 11 through 19 seem related, too, RE absolutely-positioned elements making flexbox reflow expensive.)

Comment 12

[Daniel Holbert [:dholbert]]

[Doing a pass over flexbox perf bugs to see which ones are improved by my patch posted over on bug 1492538]

This has languished a while (sorry for that), and during that time, it seems the affected site (bvsf.org) has disappeared. (It takes me to a "domain expired" page now.) So unfortunately this isn't testable/investagatable anymore.

Hence: closing as "INCOMPLETE" for now, since we don't have a testcase to examine at this point.

(Bug-reporter batogovsky: if you happen to still have a URL or a testcase that triggers this issue, please post it here and reopen the bug - thank you!)