Closed Bug 1474813 Opened 6 years ago Closed 5 years ago

Long synchronous reflows in CSS2Properties.paddingRight, at vespaclubsanquiricodorcia.cloud (probably related to "slick" carousel library)

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Version:
62 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1404140
Project Flags:
Performance Impact low
Tracking Flags:
Tracking Status
firefox62 --- affected

People

(Reporter: erotavlas, Unassigned)

References

Details

(Keywords: perf)

User Agent: Mozilla/5.0 (X11; Gentoo; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180704194937 Steps to reproduce: Hi, I have a problem about loading this Web site https://www.vespaclubsanquiricodorcia.cloud/wp/en/pictures-2017/. In particular, the pictures pages web page are loaded extremely slowly or not loaded by firefox quantum (standard 61, developer edition 62, nightly) and firefox ESR (52.9) while are loaded well by all the other browser(brave, chromium, midori or qupzilla). As you can read here https://support.mozilla.org/it/questions/1224414, I tried with different systems (dual or quad core CPU, 4 or 8 GB of RAM and video cards), different operating system (GNU/linux kernel 4.13 or windows 10, android) and the result is always the same. Hence, the point is that firefox have an issue with that kind of Web page content. The Web page uses wordpress and elements plug in with carousel https://docs.elementor.com/article/217-lightbox Can you help me? In general, firefox quantum is very fast compared to the others browsers.
Profiling the page with https://perf-html.io/ highlights that there is DOMContentLoaded event under which we have a lot of synchronous reflow caused by "get CSS2Properties.paddingRight" taking roughtly ~27ms each.
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → Layout
Ever confirmed: true
Keywords: perf
Summary: A web page is slowing down your browser: wordpress and javascript → Long synchronous reflows in CSS2Properties.paddingRight
Whiteboard: [qf]
A profile: https://perfht.ml/2NDMSPf So a restyle triggers the reflow, and there are actually three or four consecutive restyles before each reflow, one of which has a single element restyled. It would be interesting to know what element is it, and whether we really need to reflow everything for such change.
Priority: -- → P3
Flags: needinfo?(dholbert)
Whiteboard: [qf] → [qf:p3:f64]
Basically all of the meat of the profile is in the "loadSlider" function, which I think is the for the two slideshows at the top of the page. Specifically, the work seems to be in a JS call to a function "setPosition" which calls "setDimensions" which ultimately flushes layout via getting the paddingRight. If you look at the DOM of the slideshow elements, you can see there are many many children (all of which have <div class="slick-slide"> and contain an image to be displayed in the slideshow). I suspect all of these synchronous reflows (from setPosition/setDimensions calls) are for each of these "slides" as they get inserted into the page. There's some flex reflow in the callstacks, and I suppose it's possible we're reflowing subtrees that we don't need to care about because they're not dirty -- if that's the case, then the rough strategy in bug 1377253 might help here.
Depends on: 1377253
Flags: needinfo?(dholbert)
Summary: Long synchronous reflows in CSS2Properties.paddingRight → Long synchronous reflows in CSS2Properties.paddingRight, at vespaclubsanquiricodorcia.cloud (probably related to "slick" carousel library)
(In reply to Daniel Holbert [:dholbert] from comment #3) > There's some flex reflow in the callstacks, and I suppose it's possible > [...] the rough strategy in bug 1377253 > might help here. Just kidding -- flexbox isn't involved in the badness here. I tested this theory by adding my own user styles to add "display:block" to all flex containers I could find (using the "Stylus" Firefox extension) -- here's the style I used: .elementor-container, .elementor-row, .elementor-column, .elementor-column-wrap { display: block !important; } And then I reprofiled the pageload, and it's still terrible (and nsFlexContainerFrame doesn't appear in the stack during the hang at all). Profile: https://perfht.ml/2L6Y8Fe
No longer depends on: 1377253
Any updated about this bug?
Whiteboard: [qf:p3:f64] → [qf:p3]

I have this problem too. Any news?

The problem seems solved since firefox 70 on desktop GNU/linux and windows 10 both 64 bit while on firefox android 68.1 and firefox preview 1.3 both on android 9 is still present.

(In reply to erotavlas from comment #8)

The problem seems solved since firefox 70 on desktop GNU/linux and windows 10 both 64 bit while on firefox android 68.1 and firefox preview 1.3 both on android 9 is still present.

Maybe you can use mozregression to locate the fix of this issue, so that we can dup this bug into the actual fix and decide what we can do with that.

Maybe / probably bug 1404140?

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #9)

(In reply to erotavlas from comment #8)

The problem seems solved since firefox 70 on desktop GNU/linux and windows 10 both 64 bit while on firefox android 68.1 and firefox preview 1.3 both on android 9 is still present.

Maybe you can use mozregression to locate the fix of this issue, so that we can dup this bug into the actual fix and decide what we can do with that.

I would like to help, but mozregression has a bug on GNU/linux and does not work.

I tried on windows 10 1903 64 bit with latest version of mozregression and I get this error "2019-09-11T08:44:04: ERROR : Error while waiting process, consider filing a bug."
However, I get this
2019-09-11T09:43:03: DEBUG : Found commit message:
Bug 1404140 - Remove the GetCSNeedsLayoutFlush flag, as it is unneeded now. r=heycam
MANUAL PUSH: Would need to reorder the stack manually (https://bugzilla.mozilla.org/show_bug.cgi?id=1481539)
Differential Revision: https://phabricator.services.mozilla.com/D40300
2019-09-11T09:43:03: DEBUG : Did not find a branch, checking all integration branches
2019-09-11T09:43:03: INFO : The bisection is done.
2019-09-11T09:43:04: INFO : Stopped
1481539 is still open.
Since firefox 70 introduces new javascript engine and the problem is related to javascript, it could be the reason.

No, this was fixed by the optimization from bug 1404140, looking at that log. Great :)

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

(In reply to erotavlas from comment #11)

I would like to help, but mozregression has a bug on GNU/linux and does not work.

Note that the command-line version of mozregression (separate from mozregression-gui) should still work great on Linux (I use it often). For subsequent bugs, you might give that a shot. :)

Thanks for your help, in any case!

Great. Thank you to all. Now, can you tell me why firefox mobile is still affected?

That bug landed in Gecko 70, and Firefox Mobile is using Gecko 68 ESR. Firefox Preview / GeckoView will peek up the changes eventually.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #16)

That bug landed in Gecko 70, and Firefox Mobile is using Gecko 68 ESR. Firefox Preview / GeckoView will peek up the changes eventually.

Thank you. Where can I find information about the differences between geckoView and gecko?

There aren't really any relevant differences between Gecko and GeckoView for the purposes of this bug. GeckoView is just the name of the Gecko runtime on mobile these days.

The key difference here is the version-number -- as Emilio said, the fix was landed in the "version 70" nightly cycle (which is pretty new and hasn't hit an official desktop or Android release yet), whereas your Firefox Mobile is on version 68. So you should expect to see the fix in Firefox releases with version numbers 70 and newer.

If you want a more up-to-date (and still stabilizing) experience on Android, you're welcome to try "Firefox Preview": https://play.google.com/store/apps/details?id=org.mozilla.fenix . It uses our Nightly gecko code (currently at version 71), so it should include the fix.

Note that the current Firefox Android (Fennec) is locked on 68, so you have to use the new Firefox Preview (Fenix) if you need this fix.

(In reply to Daniel Holbert [:dholbert] from comment #18)

If you want a more up-to-date (and still stabilizing) experience on Android, you're welcome to try "Firefox Preview": https://play.google.com/store/apps/details?id=org.mozilla.fenix . It uses our Nightly gecko code (currently at version 71), so it should include the fix.

Firefox Preview Nightly uses GV 71 but the current version from https://play.google.com/store/apps/details?id=org.mozilla.fenix uses GV 69.

(In reply to Daniel Holbert [:dholbert] from comment #18)

There aren't really any relevant differences between Gecko and GeckoView for the purposes of this bug. GeckoView is just the name of the Gecko runtime on mobile these days.

The key difference here is the version-number -- as Emilio said, the fix was landed in the "version 70" nightly cycle (which is pretty new and hasn't hit an official desktop or Android release yet), whereas your Firefox Mobile is on version 68. So you should expect to see the fix in Firefox releases with version numbers 70 and newer.

If you want a more up-to-date (and still stabilizing) experience on Android, you're welcome to try "Firefox Preview": https://play.google.com/store/apps/details?id=org.mozilla.fenix . It uses our Nightly gecko code (currently at version 71), so it should include the fix.

I have already tried with firefox preview 1.3 as I wrote before.

(In reply to Sören Hentzschel from comment #20)

(In reply to Daniel Holbert [:dholbert] from comment #18)

If you want a more up-to-date (and still stabilizing) experience on Android, you're welcome to try "Firefox Preview": https://play.google.com/store/apps/details?id=org.mozilla.fenix . It uses our Nightly gecko code (currently at version 71), so it should include the fix.

Firefox Preview Nightly uses GV 71 but the current version from https://play.google.com/store/apps/details?id=org.mozilla.fenix uses GV 69.

Great, so the next firefox preview 2.0 version will ship it.

Yeah, once Firefox Preview gets updated to GV 70, it'll have the fix. (You can view its gecko version in Menu | Settings | [scroll to bottom] | About Firefox Preview -- the gecko version-number is shown next to a little lizard emoji.)

Sorry for mixing up Firefox Preview versions -- I'd forgotten I was on the beta channel in the Play Store. If you like, you can join that channel as well by following the steps on https://groups.google.com/forum/#!forum/fenix-nightly with the same Google account that you use for the Play Store. (Be ready for daily updates and occasional breaking changes, though.)

I tried firefox preview 2.0 and I confirm that the problem is over. The speed up compared to firefox for android is great even if still behind chromium based browser :(

Performance Impact: --- → P3
Whiteboard: [qf:p3]
You need to log in before you can comment on or make changes to this bug.