Further note, Safari eventually starts to slow down too, but Chrome appears to continue to handle it fairly well up to 26 layout levels (i.e., 84 nested flex containers) before I got bored.
Thanks for the testcase. This takes ~3s to load in Nightly on my desktop work machine, and it takes ~20s if I uncomment the innermost chunk ("Nested layout 7"). And Chrome does indeed load it near-instantaneously. It's possible that bug 1054010 will fix this; tentatively marking as dependency.
Status: UNCONFIRMED → NEW
Depends on: 1054010
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Version: 36 Branch → Trunk
Just to correct my math, I tested Chrome up to 26 layout levels, which is 78 nested flex containers, not 84.
I'm pretty sure the issue being highlighted here is the same one I'm seeing in bug 1108772. For what it's worth, the test case attached to my bug allows for some user interaction (dragging the top banner and vertically resizing the nested divs). I mention this because the issue is not simply that the page takes a long time to load/render--it's also that you can't really use it even after it has been drawn. In my test case there's a line declaring a variable named "depth" that's currently set to 11. I set this to over 300 in Chrome and it was still completely usable after loading instantly. Firefox was about dead (not responding) at a depth of 20.
Just a quick note for anyone still following this bug: you may be able to render the layout you want using the old 2009 -moz prefixed syntax. The comments and attachments in bug 1108772 outline this approach.
Sorry for the delay here. Good news -- I've verified that my local patches for bug 1054010 (and its dependencies) do indeed fix this (as I suspected in comment 3). They make the attached testcase load near-instantaneously, in a debug build, even with the inner section uncommented. In contrast, this takes several minutes to load in an un-patched debug build. I need to rework the patches a bit before they're ready for review/landing, but with any luck, I should have that bug (and its helpers/dependencies) fixed on trunk very soon now. So, I'm going to mark this as a duplicate of bug 1054010.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1054010
FWIW, I just landed a fix for bug 1054010, so this should be fixed in Nightly builds in the next few days. The regression-test that I included with that fix was based on the testcase in this bug here -- thanks for posting it! The particular nesting-pattern seems to be very good at making this bug painful & hanging the (unpatched) browser, with a relatively small amount of content, which makes for a great regression test.
Cool. I'm glad it made a difference.
You need to log in before you can comment on or make changes to this bug.