Created attachment 403554 [details] Appearance of the website when it freezes Hi. A recent change in the GitHub UI seems to freeze webkit2gtk webview from time to time. I cannot reproduce 100% of the time, but one way that I was able to reproduce it frequently was this: 1. Go on https://github.com/gcc-mirror/gcc 2. Scroll up and down for a few seconds. 3. Click on the gcc directory. I attached a screenshot showing how it looks when it freezes. Thanks to fix this bug.
Can reproduce with Ephy 3.37.3-1-ga48066bed+ WKGTK 2.29.2
Also in ToT btw.
It's not really a hang-up, I can see content animations. But the main loop seems so busy that it never fires a callback meant to interrupt the loading like in chromium. This github directory is huge and when those take too much time to load there's a callback fired from the web-page to interrupt it. Seems like this never fires in our case.
Does it happen in WPE? Looks like a problem with the source priorities.
(In reply to Carlos Garcia Campos from comment #4) > Does it happen in WPE? No. WPE works as expected. > Looks like a problem with the source priorities. Indeed.
Created attachment 403588 [details] Patch
(In reply to Carlos Garcia Campos from comment #6) > Created attachment 403588 [details] > Patch In WPE both LayerFlushTimer and DisplayRefreshMonitorTimer have a higher priority than MainThreadSharedTimer and the page works fine. But in GTK we need to set both to a lower priority than MainThreadSharedTimer for the page to work. Isn't that weird?
(In reply to Miguel Gomez from comment #7) > (In reply to Carlos Garcia Campos from comment #6) > > Created attachment 403588 [details] > > Patch > > In WPE both LayerFlushTimer and DisplayRefreshMonitorTimer have a higher > priority than MainThreadSharedTimer and the page works fine. Not exactly fine. WPE doesn't freeze because it uses async scrolling, so you can always scroll. When you click on the gcc link, start scrolling down the page. There's a point in which nothing is rendered, and you have to wait several seconds until you get the rest fo the page rendered. Now change the priority of LayerFlushTimer and DisplayRefreshMonitorTimer to 20 and try again. Now it behaves like GTK with this patch, no freezes and you always get the page rendered. > But in GTK we need to set both to a lower priority than > MainThreadSharedTimer for the page to work. Isn't that weird?
Committed r264015: <https://trac.webkit.org/changeset/264015>
This commit made imported/blink/compositing/squashing/squashing-reflection-disallowed.html flaky on GTK Release X11, but upon further investigation, this test should be marked as an actual failure (tracked in bug214060) and the expectation will be updated with the resource file it needs (in bug154076). (Just a note in case someone tracking it ends up here).