Reading offsetHeight does layout, I presume, and apparently we are doing more work than before. Can you please provide the test case that reproduces the problem, or take a trace and send it to us? See chrome://tracing

So I provide you 4 files:

- trace_web_developper.json.gz: the trace with chrome://tracing with option web developer
- trace_rendering.json.gz: the trace with chrome://tracing with option rendering
- performance_dev_tool.json: the performance report on chrome dev tools
- firefox_profile.json: the performance report on firefox dev tools (just to compare the huge gap)

Deleted: report.zip 2.7 MB

report.zip 2.7 MB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thank you for the traces. We also need the testcase from which you computed the
trace.

As per comment#5 adding Needs-Feedback label.

@Reporter: Please provide sample test case/URL for further investigation from dev team.

Thanks!

Sadly I cannot provide the source code, it's a confidential project not publicly available. Any way to help without providing the sources ?

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I found a chrome version 63. I took profiles for both of them (+ screenshot) on the exact same website and the problem can be seen clearly.
- On chrome 63, the rendering is not triggered, the navigation is smooth.
- On chrome 65, the rendering is triggered really often (~100ms).

I've tried many many things: removing a lot of classList.add/remove/toggle, wrapping all style read/write into requestAnimation frame, etc... but the rendering is still extremely slow and triggered even without changes to the DOM, class and style. It seems removing some css animations improve performances.

Deleted: 63_vs_65.zip 457 KB

63_vs_65.zip 457 KB Download

The alternative to source is a reduced test case that still demonstrates the problem.

So, I finally managed to reproduce the bug and find the origin: https://drive.google.com/open?id=13drlw8Yd1jI8FO1ieKxg2Zl5z-fpTwgC
=> all node/js packages are included (if problem, npm start), ts sources and I built a prod version (harder to read). You can test by serving 'dist/apps/myapp/' (or cmd 'npm run serve.prod'), or 'npm start'.

The bug come from the '.loading-wrapper' on index.html and the associated css (styles.scss). I did a special trick to hide this element at the end of the animation (put if far away) => This seems to trigger rendering every 100ms (display: none or removing element doesn't trigger rendering). Moreover, the rendering is executed when scrolling => Is it normal behavior (no changes in DOM, style or classes) ?

All other code is just here to populate the page and create a long rendering.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

As I understand it, you could workaround this using display: none or removing the element. Are those viable options for you?

Generally moving things a long way off screen has all sorts of side effects because you are practically increasing the size of the document. This might be pushing us into a different rendering mode by, for example, preventing caching.

Yes, I fixed it on my side with transitionend -> display: none. But this regression could potentially affect many other websites...

The page content is fixed (display: fixed) and the loader is put -1000%, -1000%, opacity: 0, so it is not visible. The strangest thing is why the rendering is triggered: nothing changed so the rendering should not be called no ? Moreover, other browsers or chrome < 65 are not re-rendering every 100ms for this specific case.

Finally (out of this bug), I'm not sur if the rendering should be triggered when scrolling the page. For me only the paint should be called, no ?

Thanks for your incredible work by the way ;)

As per comment#9 can we close this issue as wont-fix?? If not please let us know how to reproduce the issue with sample file given in comment#13.

Thanks!

Well for me it's still an impressive regression, creating huge freeze on user interface. Without more inspection on your side it's hard to know exactly what cause this bug and if other similar problem could occur in different cases (ex: maybe every website which use looping animations are affected?). But one thing is sure => this bug wasn't here before and have potentially big impact on many websites. Moreover, I'm not sure about this one, but the rendering is triggered when the user scroll which could potentially lead to important frame drop due to long rendering, when other brothers just repaint (regression ?).
To test, simply install nodejs, then npm i, npm start. Or serve 'dist/apps/myapp/' with http-server package for example.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce this issue with file given in comment#13. Tested the issue with below steps.

1. Extracted attached file.
2. Started simple HTTP server using python -m SimpleHTTPServer 8000
3. Opened index.html file in browser using http://localhost:8000/Downloads/chromebug/chromebug/dist/apps/myapp/index.html -- Observed "App Loading..." dialog even after 30 mins. Attaching screencast for reference. 

@Reporter: Please check the issue and let us know if we miss anything. Any further information on reproducing the issue would help in further triaging.

Thanks!

Deleted: 826195.mp4 1.4 MB

	826195.mp4 1.4 MB View Download

Yes, it's because the file are intended to be served as root on the path (localhost:8080/index.html) => the console shows than the files are 404. Could you please install nodejs, then npm i http-server -g. After this go on the root of the project (where package.json is present) and type 'npm run serve.prod'

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to test this issue on windows as TE team do not have node/npm setup as of now. 

Could someone from Blink>Paint team please have a look at the issue and help in triaging this further.

In fact the "Update Layer Tree" get really really worst with the last version of chrome:
=> list of 300 items of size 200x200 displayed inline block (see example I gave you). No transform, no animation.

- first print screen on chrome 63 => no lag when scrolling, no re-rendering, ~2ms Update Layer Tree
- second print screen on chrome 65 => important frame drop when scrolling, ~233ms Update Layer Tree (the real bottleneck) => more than 100 times slower than chrome 63

Same computer, same page. Only the chrome version changes.

Deleted: profile_2_63.png 16.4 KB

	profile_2_63.png 16.4 KB View Download

Deleted: profile_2_65.png 5.3 KB

	profile_2_65.png 5.3 KB View Download

Tried to setup node and npm on Windows 10 machine but seeing error in cmd prompt when seeing for node/npm version. Could someone from Inhouse team please help in triaging this issue further.

Thanks!

Deleted: 826195.png 13.7 KB

	826195.png 13.7 KB View Download

Able to reproduce in Windows 7 using chromebug.zip from #c13 in node.js 9.10.1 and npm 5.6.0.

Bisect info: 521694 (good) - 521706 (bad)
https://chromium.googlesource.com/chromium/src/+log/ac47dc85..bcb8fea0?pretty=fuller
Suspecting r521704 = a3ce2d3110a3f9177a41935daadd43ede72db553 = https://crrev.com/c/793973 by yigu@chromium.org
"Round the scroll offset synced back to main thread instead of flooring"
Landed in 65.0.3286.0

Apparently a duplicate of  issue 814673  fixed in Chrome 66 (stable on Apr, 17).

Close all terminals on windows (really important). Install node from here https://nodejs.org/dist/v9.10.1/node-v9.10.1-x64.msi (https://nodejs.org/en/). After this, open a terminal and you should be able to use node (type 'node -v'). As a last resort reboot after install ;)

@Bug reporter: can you please verify that the issue is fixed in Chrome
66.0.3358.0 or later?

Yes, fixed on chromium 67.0.3390.0. Thanks to you. I think you can close this ticket.

The NextAction date has arrived: 2018-04-16