Erratic scrolling behaviour

[gzagatti]

Current Behavior:

Scrolling behaviour is erratic. In some pages like Github scrolling will stop working. Reloading the page does not restore the behaviour. Starting a new tab and reloading the page can sometimes restore the behaviour.

Scrolling the page works even when scrolling has stopped.

Desired Behavior:

Scrolling should be always working.

How can we reproduce it (step by step):

It is not clear how to reproduce the behaviour.

Any help with looking for the causes of this behaviour would be appreciated.

Environment:

Linux Distribution & Version:
Output of luakit --version:

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

[taobert]

Well, it might help to know how you're scrolling (key bindings/mouse wheel/click and drag).
But first, your version of luakit is quite old.
Can you confirm that it's still an issue with a more recent build before people put time into troubleshooting?

[gzagatti]

It is the mouse whell which is being erratic.

Let me install the latest version and report back. I installed luakit with apt, that's why it is a bit outdated.

[taobert]

Hmm. I think i can reproduce this with current develop.
If i open https://en.wikipedia.org/wiki/Lua_people in a new tab, i can scroll the page with the mouse wheel.
If i reload, or follow a link, the scrolling no longer works.
Closing and reopening the tab restores the function.

By contrast, if i open https://en.wikipedia.org/wiki/Lua_(programming_language) in a new tab,
wheel scrolling doesn't work at all.

Edit (20220926): Both of these pages scroll sensibly in epiphany and MiniBrowser, so it looks more like a luakit problem.

[gzagatti]

That's the exact sort of behavior that I have experienced.

[taobert]

If i set a signal handler on the window for scroll events:

window.add_signal("build", function (w)
    w.ebox:add_signal("scroll", function()
	print("window scroll")
    end)
end)

it doesn't print anything when the window scrolls, but does print if trying to scroll up when at the top of the page, or down when at the bottom.
It also prints when there is a failure-to-scroll situation.
This would be consistent with there being a signal handler listening for scroll events
which actions the scroll and returns success, preventing further signal handlers from firing.
If that signal handler is somehow getting lost, or bailing out without doing the work, then the user defined one could trigger.
My grasp of signaling is not sufficient here, but i can see that if i extend the above to:

window.add_signal("build", function (w)
    w.ebox:add_signal("scroll", function()
	print("window scroll")
    end)
    w.ebox:add_signal("scroll", function()
	print("window scroll2")
    end)
end)

then both lines print, whereas adding a return:

window.add_signal("build", function (w)
    w.ebox:add_signal("scroll", function()
	print("window scroll")
	return true
    end)
    w.ebox:add_signal("scroll", function()
	print("window scroll2")
    end)
end)

prints only the first one.

For the reasons i mention in #970, this might be a webkitgtk issue (or not). (Have you tested with epiphany?)
In my hands, the code snippet in #970 to make luakit do the scrolling itself
(@swalladge's corrected version, not my original one) seems to ameliorate the problem for me,
albeit with the mentioned loss of control when there are nested scrollable sections.

[taobert]

I can no longer reproduce this using the wikipedia links i mentioned above.
Is it still affecting you?

[gzagatti]

I still have the same problem and it is very erratic. This time I have installed luakit with Nix Home Manager so I have a newer version.

luakit 6f69789a
  built with webkit 2.38.0 (installed version: 2.38.0)

Scrolling will stop when I open certain pages first. For instance, Luakit's homepage will somehow block scrolling. If the first page opened in a tab is [https://luakit.github.io/], scrolling will not work. If I then go to the Wikipedia page [https://en.wikipedia.org/wiki/Lua_people] scrolling will keep not working.

Now, if I open a new tab with a different URL, say [https://github.com/] scrolling works. If I then search for lua people with o then follow the link presented in Google's page to the Wikipedia page [https://en.wikipedia.org/wiki/Lua_people], scrolling will still work.

If I open a new tab directly with [https://en.wikipedia.org/wiki/Lua_people], scrolling will work. But if there is a tab with the Wikipedia page open where scrolling is not working and then I try to open the same page on a new tab, scrolling will not work.

As you can see, the behavior is very erratic, so it is difficult to pin down exactly the set of actions that cause the issue.

[taobert]

Ok, so the reason i could no longer reproduce it was that i'd screwed up some code, and thereby stopped settings loading.
On paring down the settings to find the culprit, i find that in my hands,
if webview.hardware_acceleration_policy is set to anything other than "Always", i can break the scrolling on Lua People.

This kinda suggests a webkit issue, but i'll keep poking around.
Can you play with webview.hardware_acceleration_policy and see whether it changes anything for you?

[jvvv]

I have been trying to narrow down what seems to be the same mouse scroll behavior for a while. After setting webview.hardware_acceleration_policy = "always", mouse scrolling has been working normally so far.

Edited for typo.
Further edit:
Forgot to mention... version 2.3.1-1 (includes e9c7693) on alpine linux edge.

[gzagatti]

After setting webview.hardware_acceleration_policy = "always" as suggested, I don't seem to face the scrolling issue anymore. I am happy to close this issue.

[averycoolbean]

currently experiencing this issue on void linux, mouse-wheel scrolling doesnt work at all and even j/k, arrow keys and pageup pagedown arent working even after attempting this workaround (though odds are i just did it wrong, fuck if i know)

[henkmet]

@averycoolbean within a browsing session you can access the settings by typing :settings (as if that's the url). You can then search for the webview.hardware_acceleration_policy and try the different options; there are three: Always, On-demand and Never.

[msdemlei]

On Thu, Aug 31, 2023 at 07:10:52PM -0700, henkmet wrote: @averycoolbean within a browsing session you can access the settings by typing :settings (as if that's the url). You can then search for the `webview.hardware_acceleration_policy` and try the different options; there are three: Always, On-demand and Never.

No, I think this one is a different problem from the classic mousewheel one. I'm observing something like this, too, since the bookworm upgrade, which was to webkitgtk 2.40.5. What seems to happen under circumstances I've not investigated more closely (because only sucky pages taking ages to "load" seem to be affected) is that scroll events are not processed for a while after/while a page is loaded. So far, I'm sort of hoping the problem (that doesn't affect me much) may disappear in the next webkit release to hit Debian. But it would certainly be valuable to see if there's some event that marks the beginning of responsiveness (DOMContentLoaded?), perhaps with a user script or a small extension.

[averycoolbean]

@msdemlei ah yes, that does match whats happening here a little better, (the main page affected is a misskey instance i use), i suppose thats cause for opening a new issue, also

this is also how i found out void linux currently has an older version of webkit2gtk than debian (2.40.0), not ideal

[xxxserxxx]

This reliably happens on github. Mouse scrolling never works, although key bindings do. It seems to be sites that are Javascript-heavy that have the most issue, and on some sites even the key bindings do not work. For me, this is consistently reliable -- if a site doesn't scroll with the mouse, mouse-scroll never works on the site.

luakit 2.3.3-15-gb143b383
  built with: webkit 2.42.1 (installed version: 2.42.1)
                 GTK 3.24.38 
                GLIB 2.78.0 
                SOUP 3.4.3 

This is a fresh build from git, EndeavourOS luakit-git.

Edit: (Really) Enabling always hardware acceleration does fix github. I thought I had it on already. PEBCAK

[taobert]

Well, in my hands, github works the way Lua_People does:
If hw accel is not Always, then github in a new webview will mouse-scroll until a subsequent page load takes place (reload or link clicked).

[xxxserxxx]

It's baaaack. I have hw accel set to always, and scrolling is mostly broken on most sites. Mouse and often keyboard, too.