Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken UI under webkit2gtk 2.26 #804

Open
aidanholm opened this issue Sep 10, 2019 · 28 comments
Open

Broken UI under webkit2gtk 2.26 #804

aidanholm opened this issue Sep 10, 2019 · 28 comments
Labels
bug

Comments

@aidanholm
Copy link
Member

@aidanholm aidanholm commented Sep 10, 2019

I'm submitting a…

Bug Report

Current Behavior

Broken UI under webkit2gtk 2.26: frozen webpages, favicons not showing

Environment

Linux Distribution & Version: Arch

@aidanholm aidanholm added the bug label Sep 10, 2019
@alex3kov

This comment has been minimized.

Copy link

@alex3kov alex3kov commented Sep 11, 2019

Two issues I''ve experienced so far:

  • When passing URLs to already running Luakit: it results in empty page and I have to reload it to display it
  • Much higher CPU usage than on WebKit 2.24
@zappathustra

This comment has been minimized.

Copy link
Contributor

@zappathustra zappathustra commented Sep 11, 2019

Upgraded to webkit2gtk 2.26 on Arch: Luakit shows blank pages, no matter the URL. Not sure they are loaded, actually. Downgraded to 2.24 and it works fine.

@7415963987456321

This comment has been minimized.

Copy link

@7415963987456321 7415963987456321 commented Sep 14, 2019

Also have this issue, reloading seems to fix it.
Don't have any issues with favicons though.-
EDIT: Holy batman, didn't notice the high cpu, constantly running at ~80%.

@Argissh

This comment has been minimized.

Copy link

@Argissh Argissh commented Sep 17, 2019

Upgraded to webkit2gtk 2.26 on Arch: Luakit shows blank pages, no matter the URL. Not sure they are loaded, actually. Downgraded to 2.24 and it works fine.

I have the same issue using webkit2gtk v2.26. I don't think they are loaded as verbose mode show that the URL is actually not requested until reload.

@aidanholm

This comment has been minimized.

Copy link
Member Author

@aidanholm aidanholm commented Sep 19, 2019

This is due to webkit2gtk 2.26 apparently no longer starting a web process for a webview until a page URL is set. Page loads are prevented by the adblock module until it's loaded its blocklists, which would happen on the web process. I'm not sure why reloading the page circumvents the load block from the adblock module.

The bigger issue is that every tab must now have its own independent web process. This means that opening a new tab must now block until the web process loads, including all lua web modules, causing a noticable delay.

My CPU usage is high, but not that high: I have CPU use around 10% from luakit on 2.26: seems to be caused by the awful hack used to detect document resizes. Still waiting for ResizeObserver to be enabled for a true fix. An interim measure would be switching to setTimeout-based polling instead of requestAnimationFrame-basde polling, since the latter forces constant redraws in the luakit process.

@gersonamoriz

This comment has been minimized.

Copy link

@gersonamoriz gersonamoriz commented Sep 25, 2019

I also having a very high CPU peak with webkit2gtk 2.26, and same problem with blank pages, CPU is so high that I had to downgrade the pkg to 2.24, still working fine after downgrade.

Two issues I''ve experienced so far:

  • When passing URLs to already running Luakit: it results in empty page and I have to reload it to display it
  • Much higher CPU usage than on WebKit 2.24

I have precisely this 2 Issues ... had to downgrade to 2.24.

@gleachkr

This comment has been minimized.

Copy link
Contributor

@gleachkr gleachkr commented Sep 28, 2019

Similar CPU issues here, with the webkit process running at 40-60% on completely loaded pages that use negligible CPU in other browsers, fixed by downgrading webkit2gtk to 2.24.

@cyberl33t

This comment has been minimized.

Copy link

@cyberl33t cyberl33t commented Oct 1, 2019

When using webkit2gtk-2.26.x + libsoup-2.68.x (on Arch Linux) I get completely blank screen on luakit, with only red "[notrust]" warning at the bottom; happened on every website I was trying to go. With combination webkit2gtk-2.24.x + libsoup-2.67.x luakit works as intended.
I found somewhere an old bug report describing a similar issue, libsoup being the culprit then. But that was years ago, and has been fixed since. I'm not sure which one is wrong here this time, webkit2gtk or libsoup.

@aidanholm

This comment has been minimized.

Copy link
Member Author

@aidanholm aidanholm commented Oct 1, 2019

That sounds like this bug; the root cause is outlined in my earlier comment. I'm currently experimenting with ways to fix this, but it's still pretty experimental (read: buggy).

@nst0022

This comment has been minimized.

Copy link

@nst0022 nst0022 commented Nov 13, 2019

Same here on Debian after upgrade to
libwebkit2gtk-4.0-37:amd64 2.26.2-1~deb10+1
(1) page is empty until reloaded
(2) high CPU when window is open, low if iconified

@zappathustra

This comment has been minimized.

Copy link
Contributor

@zappathustra zappathustra commented Nov 15, 2019

Now webkit2gtk 2.24 seems to be broken in Arch (missing libicuuc.so, iirc), so you have to run/build with 2.26. And like @nst0022 pages won't load at first in an new tab. Next requests are ok, pages are loaded, but it's annoying when opening in an new tab (you have to reload once each time).

Tried switching to the official pacman binary but it's the same problem.

@nst0022

This comment has been minimized.

Copy link

@nst0022 nst0022 commented Nov 15, 2019

Thanks for this hack, which works once, when luakit is started with a URL.

However, if I click a link on a page with the middle mouse button, which should open the link in a new tab, then I have to manually reload the tab for the content to be displayed.

Note, that I have re-applied the hack here locally in the version from the Debian repository, which is

luakit 2.0.0
  built with webkit 2.22.6 
  (installed version: 2.26.2)

The version from GitHub might run better.

@Duchys

This comment has been minimized.

Copy link

@Duchys Duchys commented Nov 15, 2019

Had the same problem when starting luakit with URL on Rasbian since upgrading webkit2gtk to version 2.26

Simply disabling adblock in rc.lua resolved this problem for me.

@nst0022

This comment has been minimized.

Copy link

@nst0022 nst0022 commented Nov 15, 2019

@Duchys : You are amazing.
Indeed this works, even without the hack.

@zappathustra

This comment has been minimized.

Copy link
Contributor

@zappathustra zappathustra commented Nov 16, 2019

@nst0022 - The version in Debian is quite old, I can't really investigate. But anyway:
@Duchys - Indeed the culprit seems to be:

    webview.modify_load_block(view, "adblock", true)

on line 462 of adblock.lua. But then I don't know what webview.modify_load_block() does, so I can't help further (I'm not familiar with webview.lua). Quite possibly it simply loads whatever adblock is supposed to do, so the real problem is elsewhere in adblock.lua

@nst0022

This comment has been minimized.

Copy link

@nst0022 nst0022 commented Nov 16, 2019

Not, that it gets lost, the high CPU usage problem still exists, with or without the disable-adblock-workaround.

@aidanholm

This comment has been minimized.

Copy link
Member Author

@aidanholm aidanholm commented Nov 16, 2019

@zappathustra see #804 (comment) for what modify_load_block() does. Basically, the problem is caused by the (now per-tab) process not being started, so adblock rules are never loaded, and the adblock module never finishes loading.

A partial fix is to add this to init_funcs in lib/webview.lua:

    ensure_web_process_loaded = function(view)
        view:add_signal("switched-page", function (v)
            if not webview_state[v].process_loaded then
                if v.uri ~= nil then
                    v.uri = ""
                end
                webview_state[v].process_loaded = true
            end
        end)
    end,

This adds an extra "about:blank" history item to most tabs, so it's not ideal.

@aidanholm

This comment has been minimized.

Copy link
Member Author

@aidanholm aidanholm commented Nov 16, 2019

One possible alternative would be to navigate to about:blank in C, and hide the additional tab history item from lua.

@zappathustra

This comment has been minimized.

Copy link
Contributor

@zappathustra zappathustra commented Nov 16, 2019

@aidanholm I see, sorry I didn't read the thread properly!

@alex3kov

This comment has been minimized.

Copy link

@alex3kov alex3kov commented Nov 18, 2019

FWIW - the high CPU issue is also present in Midori 8.0 but not in Epiphany 3.35.1 (using webkit2gtk 2.26.2).

@gleachkr

This comment has been minimized.

Copy link
Contributor

@gleachkr gleachkr commented Nov 18, 2019

Also (adding to @alex3kov), the CPU issue appears to not be present in surf 2.0.

@aidanholm

This comment has been minimized.

Copy link
Member Author

@aidanholm aidanholm commented Nov 18, 2019

@zappathustra No worries:)

CPU usage is likely an artefact of how luakit polls for changes to document height, in extension_scroll.cc. This seems to cause constant repaints starting from 2.26. That should be slightly more straight-forward to fix, by not using RAF, and adding a mechanism to restrict polling to currently visible webview widgets (which RAF does).

@msdemlei

This comment has been minimized.

Copy link

@msdemlei msdemlei commented Nov 26, 2019

Here's a dumb question: Wouldn't setUsesSingleWebProcess(true) help? I
freely admit I've not actually researched the situation but just looked
at a patch of the Debian webkit package, as in here:

https://git.launchpad.net/ubuntu/+source/webkit2gtk/tree/debian/patches/force-single-process.patch?h=debian/buster

@msdemlei

This comment has been minimized.

Copy link

@msdemlei msdemlei commented Nov 26, 2019

Here's a dumb question: Wouldn't setUsesSingleWebProcess(true) help? I
freely admit I've not actually researched the situation but just looked
at a patch of the Debian webkit package, as in here:

https://git.launchpad.net/ubuntu/+source/webkit2gtk/tree/debian/patches/force-single-process.patch?h=debian/buster

Replying to myself, that's clearly at least not nearly enough: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945509

@HollMax

This comment has been minimized.

Copy link

@HollMax HollMax commented Dec 3, 2019

@zappathustra No worries:)

CPU usage is likely an artefact of how luakit polls for changes to document height, in extension_scroll.cc. This seems to cause constant repaints starting from 2.26. That should be slightly more straight-forward to fix, by not using RAF, and adding a mechanism to restrict polling to currently visible webview widgets (which RAF does).

Any updates on this? If no, where should I look to do this? I haven't made any contributions to LuaKit yet and I haven't been using it for long either, so I don't know my way around the code base.

@sprnza

This comment has been minimized.

Copy link

@sprnza sprnza commented Dec 5, 2019

Is hints color got black related issue?

@nst0022

This comment has been minimized.

Copy link

@nst0022 nst0022 commented Dec 5, 2019

@HollMax: I guess with "extension_scroll.cc" @aidanholm meant "extension/scroll.c", where there is a function "check_for_document_resize" you could start with.

@HollMax

This comment has been minimized.

Copy link

@HollMax HollMax commented Dec 9, 2019

Basically the functions we use have been deprecated in 2.22, so they might have been broken in some way. Unfortunately there's no recommended replacement in WebkitGTK's documentation, so I can do a quick replacement and I don't have enough time to take a deeper look at what and why we're doing in extension/scroll.c and how to do it using JavascriptCore APIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.