1108772 - Updates to DOM elements are extremely slow when nested flexbox elements are present

Status: RESOLVED DUPLICATE of bug 1142686

(Core :: Layout, defect)

Description

[Mike]

Attachment: Nested flexbox elements resulting in laggy performance

I'm working on a web app that allows the user to dynamically grid up the space in their window. Essentially, the body is converted to a flexbox and the user is able to arbitrarily insert additional cells (divs) that display as flexboxes. Each cell can contain either additional cells or some content, where the content is some arbitrary structure of divs, spans, and other generic HTML tags. The result is ultimately that the user can generate their desired page layout (columns within rows, within columns, etc.) of different widgets.

I have this fully implemented and it works great without any issues in Chrome. In Firefox the performance is unfortunately completely unusable. Any user interaction with the grid (such as resizing a cell) or working with a widget is incredibly laggy. I've attached a test file here that demonstrates the problem.

In the attached test file, the user can interact with the banner of Firefox logos at the top by clicking and dragging horizontally. If you do this, the background image will be dragged and three values (which are of no importance) will be displayed. These three values are inserted into child divs within the draggable banner. If the updating of these elements is not performed (all the calculations can still be done, we just omit the lines involving setting innerHTML) the dragging performance is equivalent to Chrome. If the updating is performed, the interaction is so laggy it's unusable. Note that the draggable banner is *not* deeply nested within the flexboxes (though in my actual application it is).

Additionally, I set some of the divs to be resizable and you can observe the lag by dragging the thicker black lines up and down. Again, Chrome has no issue handling this.

Note that while I'm using jQuery to handle the user interactions, the updating of the three divs with non-important values uses raw innerHTML JS so the issue is independent of the JS library being used.

The interesting thing about this is that the interactive elements don't have to be nested within the flexbox divs. As long as there are multiple levels of nested flexboxes, the user interactions are slow across the board for the entire page.

Comment 1

[Mike]

Attachment: Nested flexbox elements resulting in laggy performance (fixed for HTTPS viewing)

I just realized that the attachments load via HTTPS, so I corrected my original test file to properly pull in the Google-hosted jQuery files.

Comment 2

[Mike]

Attachment: Identical page layout using the 2009 flexbox spec that is not laggy

For what it's worth, the old 2009 syntax doesn't result in any performance problems and gives me all the functionality I need for my UI. The attached file renders an identical page to the original attachment, but user interactions are not laggy and performance is just about equivalent to Chrome. The primary difference is a replacement of the current flexbox CSS syntax with the old 2009 -moz prefixed syntax. In my actual application I can notice a slight performance difference (with Firefox being a tad slower) when resizing elements, but it's very minimal and still completely usable.

Note that I did have to make a few small changes to my HTML so that the old syntax would render as I expected it to. In all cases the changes revolved around having to wrap content in generic div containers so their height and/or width would be preserved. This was especially true for any elements that had margins and/or padding defined, such as a div with a background image, no internal content, a fixed size, and some amount of padding. Adjusting box-sizing did not affect the resulting size of the element and the padding always ate into the desired size (so a height of 10 pixels with 2 pixels of padding above and below would render as 6 pixels high with 4 pixels of padding total).

If you take a look at this new file you'll see that I had to wrap the "<NUMBER>b" strings in their own div so that the content would be displayed as a column. As described above, this was a case I encountered in my application where wrapping some content in a generic container solved the issue.

Of course the performance issue still resides in the current Firefox trunk, but if any other devs come across this page seeking a solution for the same problem there may be some mileage to be had with the old 2009 syntax. In my case I simply use a Chrome-specific stylesheet (via a media query) using the current syntax and fall back to the 2009 -moz prefixed syntax if the page is loaded in Firefox.

Comment 3

[Daniel Holbert [:dholbert]]

I've duped bug 1082780 to bug 1054010 (see that bug for more details). Updating "depends-on" field here to account for this.

I'm not marking *this* bug as a dupe (at this point), because the testcase here still has noticeable hangs even with my patches for bug 1054010 applied.  So there may be some more that needs doing here, beyond the strategy in bug 1054010. I'll investigate further once bug 1054010 is closed out.

Comment 4

[Artur]

Attachment: Extremely slow rendering of nested flexbox elements

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]:
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: 
[String/UUID change made/needed]:

Comment 5

[Artur]

I experienced the same problem. A html code within our e-commerce software, contains a lot of deeply nested div containers that use “display:flex” attribute.
On Firefox page renders extremely slowly (around 30-60 seconds, sometimes freezes completely) which made it completely useless.
On other browsers (Chrome, IE, Safari) it renders in 2 seconds maximum.

Problem occurs for:
Firefox release - 35.0.1
Firefox Developer Edition - 37.0a2 (2015-02-11)

I attached a test case ( Extremely slow rendering of nested flexbox elements ), however you can also use a live application that is available under the url: 
www.marketkablowy.pl?DEV=1&WORKLOCAL=4&CPG=278B211C-4F78-4A10-B663-30A8B1F7C920&csB2BPortalsStart=E211E723-E9B8-41D7-AE19-62E6C5CA27C1&SD=0&NS=94c81da5-99bb-48f6-93cc-73b72f5938d3&Skin=94c81da5-99bb-48f6-93cc-73b72f5938d3&Title=www.marketkablowy.pl

Comment 6

[Daniel Holbert [:dholbert]]

Artur: I can reproduce the hangs you describe, at the live URL, in Firefox release version (not 30-60 seconds on my end, but definitely noticable multi-second hangs).

Good news -- they seem to be fixed in our Nightly version (v38) -- I didn't notice any hangs there. So, that problem was likely fixed by bug 1054010.

If you'd like to try a Nightly build to test / confirm this on your end, you can get one here:
 http://nightly.mozilla.org/

Comment 7

[Artur]

Daniel, thank you very much for these good news!

On Nightly version our application works great. I'll test other solutions where we're using flexboxes and if eventually notice any rendering performance problems, I'll report them here.

Thank you again.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Artur from comment #7)
> On Nightly version our application works great.

Hooray! Thanks for the confirmation.

> I'll test other solutions
> where we're using flexboxes and if eventually notice any rendering
> performance problems, I'll report them here.

Thanks! Though -- it's probably better to file new bugs, actually (and feel free to CC me to be sure they're not overlooked) -- because it's hard to tell up-front whether two performance problems are really the same underlying issue.  We can always mark bugs as duplicates after the fact, if & when we determine that they're the same. (e.g. if a fix for one of them fixes the other as well)

Comment 9

[Daniel Holbert [:dholbert]]

Comment on attachment 8563356 [details]
Extremely slow rendering of nested flexbox elements

(Marking Artur's testcase as obsolete, since per comment 6 & 7, it seems to have been fixed by bug 1054010 & hence is not this bug.)

Comment 10

[Daniel Holbert [:dholbert]]

Great news -- the testcase here seems to be fixed in today's nightly! (When clicking & dragging the row of firefox logos, there's maybe 1/2-second lag time in yesterday's Nightly, but no noticable lag in today's nightly.)

Fix range (from yesterday's nightly to today's):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=af68c9c0e903&tochange=436686833af0

Hence, fixed by bug 1142686. I'm forward-duping this to bug 1142686, since that's where the issue ended up being isolated & fixed.

Comment 11

[Mike]

(In reply to Daniel Holbert [:dholbert] from comment #10)
> Great news -- the testcase here seems to be fixed in today's nightly! (When
> clicking & dragging the row of firefox logos, there's maybe 1/2-second lag
> time in yesterday's Nightly, but no noticable lag in today's nightly.)
> 
> Fix range (from yesterday's nightly to today's):
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=af68c9c0e903&tochange=436686833af0
> 
> Hence, fixed by bug 1142686. I'm forward-duping this to bug 1142686, since
> that's where the issue ended up being isolated & fixed.
> 
> *** This bug has been marked as a duplicate of bug 1142686 ***

That's fantastic--thanks for the hard work on these flexbox issues, Daniel. I'll try out the nightly tomorrow when I have my application's source available to me.

Comment 12

[Mike]

(In reply to Mike from comment #11)
> (In reply to Daniel Holbert [:dholbert] from comment #10)
> > Great news -- the testcase here seems to be fixed in today's nightly! (When
> > clicking & dragging the row of firefox logos, there's maybe 1/2-second lag
> > time in yesterday's Nightly, but no noticable lag in today's nightly.)
> > 
> > Fix range (from yesterday's nightly to today's):
> > https://hg.mozilla.org/mozilla-central/
> > pushloghtml?fromchange=af68c9c0e903&tochange=436686833af0
> > 
> > Hence, fixed by bug 1142686. I'm forward-duping this to bug 1142686, since
> > that's where the issue ended up being isolated & fixed.
> > 
> > *** This bug has been marked as a duplicate of bug 1142686 ***
> 
> That's fantastic--thanks for the hard work on these flexbox issues, Daniel.
> I'll try out the nightly tomorrow when I have my application's source
> available to me.

Just FYI: I tested the latest nightly with my application this afternoon and the lag has indeed been fixed. Thanks again, Daniel!