major rendering issues on some sites with the latest webkit

[balejk]

Current Behavior:

Some websites such as Github freeze upon loading -- there is no feedback from the page, it does not respond to window resize, although it seems that for example hovering over some elements does detect them.

Desired Behavior:

All sites should render properly and stay responsive.

How can we reproduce it (step by step):

Start the latest luakit with the latest webkit (2.42.5), navigate to https://github.com/luakit/luakit/issues, try to use the page. It should freeze almost immediately.

Environment:

Linux Distribution & Version: Void Linux (but others have reproduced this with other distributions too)
Output of luakit --version:

luakit 2.3.6
  built with: webkit 2.42.5 (installed version: 2.42.5)
                 GTK 3.24.38 
                GLIB 2.78.0 
                SOUP 3.4.2 

---

Please see the corresponding Void issue for more details.

I was unable to reproduce this issue with epiphany or the MiniBrowser bundled with webkit. According to reports, the issue does not occur with nyxt either.

Note that this issue does not occur with the latest luakit and webkit 2.40.0.

HOME=/tmp/home luakit --log=debug > debug.log 2>&1 (start luakit, navigate to luakit Github repository, fiddle around a little, quit): debug.txt

[ghost]

can't reproduce the crash, but the window resize freeze does occur for me. After resizing, the parts that have not been updated yet have the default background color (grey in my case), but hovering over them does detect elements

luakit 2.3.6-15-g2f633b31
  built with: webkit 2.42.5 (installed version: 2.42.5)
                 GTK 3.24.41
                GLIB 2.78.4
                SOUP 3.4.4

[balejk]

can't reproduce the crash,

You mean the crash from the other issue?

After resizing, the parts that have not been updated yet have the default background color (grey in my case), but hovering over them does detect elements

That sounds exactly as what I'm experiencing. In case that it is not clear from my original description, let me add that for instance scrolling does not work either -- or more precisely, it does not render the scrolled page, but having mouse hover somewhere on the page does seem to detect the elements which get scrolled under it.

[ghost]

must've misread freeze as crash, my bad.

but yeah, scrolling is broken too. refreshing fixes the issue though, and the page works fine again afterwards (until you resize luakit again)

[balejk]

refreshing fixes the issue though, and the page works fine again afterwards (until you resize luiakit again)

Hmm, I didn't observe that it would be caused by resize in my case. For me, it just freezes right after the page is loaded and the broken scrolling and resizing are just consequences. Refresh doesn't really fix it for me either, although sometimes it does render the scrolled part of the page after refresh.

[jlzht]

Openning Github without a account logged dont cause this issue, is there other pages where this unresponsive behavior happens?

[balejk]

So, it seems that a Google search results page is another one where it happens, although I cannot reproduce it there always and also it sometimes doesn't break immediately. As for Github, I am not logged in either.

[jlzht]

Sorry, I actually got it working using noscript module, disabling scripts on a GitHub domain in a priv-tab (no login). I also found this issue on Steam support page (logged), as for Google, searching from www.google.com breaks instantly for me. Duckduckgo sometimes behaves similarly.

Also, I dont know if this is happening only on my machine, but after the freezing, :log, :settings, :binds, etc present a blank screen and dont load.

[balejk]

Also, I dont know if this is happening only on my machine, but after the freezing, :log, :settings, :binds, etc present a blank screen and dont load.

This doesn't happen for me if I issue `:log` as that opens a new tab. But if I navigate to luakit://log from the broken tab, then it does not work, as doesn't any other page -- the entire tab simply remains broken.

[jlzht]

By setting webview.hardware_acceleration_policy = "always", I was unable to get any error, on-demand doesnt do anything it seems, using follow still crashes git page sometimes.

luakit 2.3.6
  built with: webkit 2.42.5 (installed version: 2.42.5)
                 GTK 3.24.38 
                GLIB 2.78.0 
                SOUP 3.4.2 

[balejk]

Thank you very much for sharing your observation! I can confirm that setting `hardware_acceleration_policy = "always"` mitigates the problems for me too. Interestingly enough though, I don't seem to observe the problems with the policy set to `"never"` either. So it seems that `"on-demand"` is the only problematic choice. Could you please confirm that you are seeing the same thing? It seems that this setting is being passed to WebKit pretty straightforwardly so the problem could be with WebKit itself after all, but I don't know the code enough to be able to tell for sure, so I would appreciate some confirmation before trying to submit the report upstream. It would also be nice if we could reproduce this with some other WebKit based browser -- do you know of any which expose this setting too?

[jlzht]

Yeah... confirming, the rendering issues only appear when "on-demand" option is set. Running luakit with env variable WEBKIT_DISABLE_COMPOSITING_MODE=1 disables hardware acceleration altogether, also mitigating the problem. About webkit-based browsers, maybe vimb has the option to set hardware acceleration policy, Epiphany also according to arch-wiki. I cannot install these browsers on my machine at the moment to test.

Maybe someone at the void issue can also confirm this behavior in other browsers, for better upstream report.

[oreo639]

You can't test ondemand with a modern epiphany since it uses webkitgtk-6.0, which removed the ondemand option: WebKit/WebKit@7e5444b

I tried enabling "ondemand" hardware acceleration policy in the webkit2gtk-4.1 MiniBrowser and haven't noticed any issues.
I also can't reproduce the issue in vimb, which enables ondemand by default: https://github.com/fanglingsu/vimb/blob/dd7c3a652fcdf5420c5e8ed249f260c43e400809/src/setting.c#L99
Even after doing :set hardware-acceleration-policy=ondemand, I still cannot reproduce the issue.

But, yeah, using :set webview.hardware_acceleration_policy always or :set webview.hardware_acceleration_policy never in luakit does appear to workaround the issue.

[balejk]

Thank you both for testing. I am definitely seeing some issues with vimb although they do not seem to occur as reliably as with luakit. Most often I have experienced rendering lags at https://github.com/pricing. Note that I had to open new window for the hardware policy change to take effect (judged by the occurence of the lags, although since the reproduction isn't reliable, it might have just been a coincidence). I have not been able to reproduce the problems with the MiniBrowser, which is unfortunate, as that would be the best ground for an upstream report. I have set the policy through the browser settings prompt though and as such I am not 100 % confident that it has taken effect (given what I write in the previous paragraph) even when I opened new tabs. Is there a way to set this on the MiniBrowser startup or have it default to it somehow?

[PluMGMK]

Yeah... confirming, the rendering issues only appear when "on-demand" option is set. Running luakit with env variable WEBKIT_DISABLE_COMPOSITING_MODE=1 disables hardware acceleration altogether, also mitigating the problem.

Ah, thank you so much for this, I've been dealing with this problem for what feels like over a year at this point (certainly longer than this GitHub issue has been here), and setting this env variable does indeed finally fix it! :) Just recently, DuckDuckGo's results page started breaking systematically too, so things had gotten really bad…

If this is an issue with hardware acceleration getting turned on/off, is it worth people with affected/unaffected systems posting their graphics driver info? I'm using mesa with the radeonsi driver on an AMD Radeon RX 5500 XT and am affected…

[jlzht]

If you were dealing with this problem over a year, maybe it is not related with webkit version at all? I am also using mesa-radeonsi drivers, with AMD 5500U, someone with a different graphics card should check I guess.

Upon futher investigation, for me it seems the problem is with luakit itself, try experimenting this:

• enable on-demand option.
• open this repo issue field and see if the rendering freezes
• try to move using HJKL, gg or GG, or click on a link.
• Move your mouse in and out of the browser window region repeatedly.

After some delay your request will be processed and the page will be rendered with the scroll offset or new link(even follow works). you can also try openning :bookmarks or any other windows from the freezed one. I am not a proficient with lua programming, but I think the issue might be that ´"expose"´ signal not being emmited, when ´on-demand´ is activated. The freezing might be just the browser waiting for the emit signal, I am not sure.

[PluMGMK]

If you were dealing with this problem over a year, maybe it is not related with webkit version at all? I am also using mesa-radeonsi drivers, with AMD 5500U, someone with a different graphics card should check I guess.

I'm pretty sure I started experiencing it after the libsoup3 changeover, which would imply a connection to newer WebKit versions. I remember being an early adopter due to following all the software in the development version of Beyond Linux from Scratch, so it might have hit me sooner than distro users. I may be misremembering though, it might only have started after a later upgrade. But it's definitely been going on for a long time…