725437 - Unstable rendering of dynamic elements in a deeply nested table structure with large scrolling content and percentage heights on table descendants

Status: NEW

(Core :: Layout, defect)

Description

[James Wheare]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

Please see this minimal reduction of an irccloud.com layout that exhibits the buggy behaviour:

http://dl.dropbox.com/u/175535/firefox-unstable-height.html

IRCCloud is a complex app and this sort of layout is sadly necessary until things like display: box are better supported (even the browsers that support it experimentally have show stopper bugs)

Two columns are each within a deeply nested table structure (3 levels seems to be the minimum to produce this issue).

Each cell in the nesting structure has 100% height.

The right hand column in orange contains a 100% height, overflow: auto div absolute positioned, inside a relatively positioned wrapper div, within which is an unordered list with 1200 generated children (identical behaviour is exhibited if the children are hard coded into the html, the example generates them with js for readability)

The left hand column in purple has a div that has it's innerHTML set with the current time every 100ms.

Different elements are coloured to clarify what's happening.



Actual results:

The combination of the left hand column's content changing, the right hand column having many children and the 100% nested table cell layout seems to be very unstable. Scrolling, triggering keypresses and moving the mouse (even when the window isn't focused) all cause the elements to flash off and on (seemingly due to their height being briefly set to 0)



Expected results:

I would expect all the elements not to react so violently to mouse/keyboard events that don't even touch them.

Comment 1

[James Wheare]

Attachment: Linked test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

So this page creates a huge table, then modifies one of the cells every 100ms.  That triggers a reflow of the whole table.  If that reflow takes long enough and the user is trying to interact with the browser, then the reflow will be interrupted partway through so that the user interaction can be serviced.  When _that_ happens the table will be in a partially-laid out state; some of the heights may in fact be wrong at that point.

The interrupted reflow will resume at some later point off the event loop, and the sizes will get updated, but in the interim you can get flicker.

If I turn off interruptible reflow, the flicker disappears.

By default, the interrupt only happens when reflow is taking over 100ms and the user is trying to interact with the browser...

Of course you can work around this by forcing a (non-interruptible) layout flush after the change that triggers the relayout.  But of course that would mean that every time you do that the page will stop responding to user input for the duration of the reflow (which is at least 100ms in this case sometimes; I just checked and on my fairly fast laptop it's between 30ms and 120ms depending on what else is going on, apparently).

On our end, we could try to do something about leaving whatever block is involved in a "better" state during a reflow interrupt, I guess...  It's not clear how much that would help.  We could also try to make this reflow just run faster...

Comment 3

[Boris Zbarsky [:bzbarsky]]

Looking at what takes so much time, we're reflowing the whole list of members.  Why is that happening?  I wouldn't think that subtree is dirty... This happens even if I make the table table-layout:fixed and give it a fixed width, so I don't think it's a matter of just widths changing.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, it's special height reflows that are the problem.  If I just remove all the percentage heights from table descendants then our reflow times drop down to the 0-1ms I see in other browsers....

Comment 5

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

Matt, should this be fixed by DLBI?

Comment 6

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

In comment #5, I was referring to the continuous paint flashing even when the HTML and textContent aren't changed.