Bug 266433 – Slow forced layout and paint in browser on initial load and scroll

• Status: NEW
• Component: Layout and Rendering

[Will Kashdan]

Created attachment 469043 [details]
Video of the Vuejs app while scrolling up and down

Component: Layout and Rendering, initial browser load, scrolling

OS: macOS Sonoma 14.2, Ipad 17.1
Safari: Version 17.1, 17.2

Summary: Scrolling with mouse causes white screen during layout invalidation / forced layout calculations

Steps to Reproduce:

My team fixed the bug in our production application, however I was able to replicate the issue with a small VueJS web application

1) Pull this small git repo https://github.com/wkashdan/forced-layout-app

2) npm install, npm run serve (in a current version of node, I was using 18)

3. Visit localhost:8080, you will see images render on the screen, the code randomly changes image sizes, and logs the positioning of image to force a layout invalidation and forced layout.

4. Scroll up and down in the browser, you are likely to see some white frames between paints. When using the scrollbar this does not happen. This also does not happen in chrome with either mousewheel or scrollbar. 

Result: occasional white screens frames
Expected Results: Smooth scrolling, no white screens 

Additional details:
While I was only able to replicate a few white frames in this example, it was much worse on our production application, taking sometimes 500ms to 1.5 seconds to render content on scroll. We think this was a regression however we have been unable to pinpoint a version of Safari or an OS tied to this.

[Simon Fraser (smfr)]

Is this worse in Safari 17 than earlier versions?

[Radar WebKit Bug Importer]

<rdar://problem/119691768>

[Simon Fraser (smfr)]

Also a non-npm way to view the content would speed investigation. The instructions see to assume that you have vue installed already.

[Will Kashdan]

Hey Simon, thanks for the quick response. 

I updated the repo to specify a global npm registry, it shouldn't have any global dependencies, with node 18+ try it again and see if it works now. 

I just tried testing on previous versions of safari using simulator and it does appear this issue is present. Maybe this is not a regression, but a general performance issue in comparison to chrome. 

We still think there was a regression, but my code may not be replicating that same regression. I'll spend some more time next week trying to replicate / investigate the possible regression. 

The production code is much more complicated than this code so it can be difficult to replicate the exact scenario. 

Thanks again,
Will