Closed
Bug 1149339
Opened 10 years ago
Closed 10 years ago
Nested Flexbox Performance Is .... Unusable (version 36.0.4)
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: mike.thompson, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36
Steps to reproduce:
Run our demo program which makes use of deeply nested flexboxes:
http://re-demo.s3-website-ap-southeast-2.amazonaws.com/
Click among the Left-Hand-Side nav items. Generally interact with the app.
Actual results:
Notice the BIG pauses in clicking from one LHS nav item to another, or performing other basic UI interactions.
Expected results:
Both Chrome or IE11 effortlessly handle our app. Firefox is soooo slow. Nested flexbox layouts are only going to be used more or more in the future.
Comment 1•10 years ago
|
||
On Firefox 37 the page loads and is really sluggish.
On Nightly 40 nothing shows up, all blank.
Chrome 42 is fast and smooth.
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Product: Firefox → Core
Comment 2•10 years ago
|
||
Nested-flexbox performance should already be getting a lot better in Firefox 38. (from bug 1054010 and bug 1142686)
The change to a blank page is interesting, though - taking a look...
Comment 3•10 years ago
|
||
When I load the page in Firefox Developer Edition or Firefox Nightly, I get this in my error console:
> ReferenceError: re_demo is not defined re-demo.s3-website-ap-southeast-2.amazonaws.com:23:16
I don't get that error in Firefox Release. That seems likely to be due to a DOM or JS-engine change.
Comment 4•10 years ago
|
||
(And I think that error is the reason the page ends up blank.)
Comment 5•10 years ago
|
||
I spun off bug 1149604 for the blank page issue. Once we've sorted that out & can get the page here to render, we can see if the already-landed flexbox perf improvements (from comment 2) have fixed the perf issues here.
Depends on: 1149604
Comment 6•10 years ago
|
||
The blank page issue seems to be due to the page using a version of ClojureScript that's not compatible with ES6 regexp stuff... Mike, there's some discussion about how common use of such ClojureScript versions is over in bug 1138325. If you have any relevant data (e.g. how you came to be using such a version), putting that information there would be much appreciated!
Comment 7•10 years ago
|
||
I tested the first Try build from Bug 1138325 comment 15 [1] (which gets me past the JS regexp error). With that, I can confirm that there's no noticeable perf difference between Firefox and Chrome in version 38.
(It's *much* better than Firefox 36, which has 1+ second delays when I resize the window or click an entry in the left sidebar.)
So, I'm going to call this WORKSFORME in trunk (almost certainly fixed by bug 1054010 or its expansion/improvement in bug 1142686). Though note that you can't see the "WORKSFORME" behavior until the site renders, as tracked in bug 1138325. (And it sounds like you may want to use a different ClojureScript version?)
[1] http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/arai_a@mac.com-d8cdba5c8acf/try-linux64/firefox-38.0a2.en-US.linux-x86_64.tar.bz2
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Comment 8•10 years ago
|
||
(So, this is effectively a dupe of bug 1141108, though I'm not marking it as such because it's hard to be 100% sure about exact fix range here, due to bug 1149604)
See Also: → 1141108
Reporter | ||
Comment 9•10 years ago
|
||
Thanks! Later today we will:
1. move to the newer version of clojurescript and upload a revised version of the app.
2. test with Firefox nightly
3. report back here.
Comment 10•10 years ago
|
||
Sounds great, thanks.
Reporter | ||
Comment 11•10 years ago
|
||
We've deployed a new version of our app, based on the latest clojurescript. So that should fix the "JS regexp error" which caused a blank page on "version 38".
As before: http://re-demo.s3-website-ap-southeast-2.amazonaws.com/
But I'm having trouble testing this myself. Firefox versioning is confusing me.
I just went to the nightly downloads page (https://nightly.mozilla.org/) and got the file "firefox-40.0a1.en-US.win64.installer.exe" (Windows 64bit), the naming of which lead me to believe I was getting the firefox 40.
But when I run it (after upgrade process happens), the "About Mozilla Firefox" page reports version 37.0
On that version, flexbox performance is still poor, and clearly inferior to Chrome. But there's obviously a later version which I can't seem to download and run.
Comment 12•10 years ago
|
||
If you already had Firefox 37 running (with a window open), when you tried to start Firefox 40, then we just pop up a new window in your already-running Firefox 37 instance. (This is confusing and surprises people; I think it's to avoid profile corruption, from having e.g. both versions writing to your history at the same time.)
Could you test Firefox Developer Edition:
https://www.mozilla.org/en-US/firefox/developer/
Unlike Nightly, that uses its own profile -- separate from your normal Firefox installation -- which means it'll happily run alongside Firefox. (It's also easier to distinguish immediately, since it uses a dark theme.) This isolation will also reduce the (small) risk that Nightly does something silly & corrupts your normal browsing profile.
Reporter | ||
Comment 13•10 years ago
|
||
Confirming: nested-flexboxes look snappy on Developer Edition "38.0a2 (2015-03-30)"
Comment 14•10 years ago
|
||
Great, thanks! (& thanks for filing the bug in the first place)
Marking 'verified' based on comment 13.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•