Bug 213970 – [GTK] WebProcess hangs when browsing GitHub

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[antoyo]

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.

[Philippe Normand]

Can reproduce with Ephy 3.37.3-1-ga48066bed+ WKGTK 2.29.2

[Philippe Normand]

Also in ToT btw.

[Philippe Normand]

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.

[Carlos Garcia Campos]

Does it happen in WPE? Looks like a problem with the source priorities.

[Philippe Normand]

(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.

[Carlos Garcia Campos]

Created attachment 403588 [details]
Patch

[Miguel Gomez]

(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?

[Carlos Garcia Campos]

(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?

[Carlos Garcia Campos]

Committed r264015: <https://trac.webkit.org/changeset/264015>

[Lauro Moura]

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).