-
Notifications
You must be signed in to change notification settings - Fork 245
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
Erratic scrolling behaviour #1007
Comments
Well, it might help to know how you're scrolling (key bindings/mouse wheel/click and drag). |
It is the mouse whell which is being erratic. Let me install the latest version and report back. I installed luakit with |
Hmm. I think i can reproduce this with current By contrast, if i open https://en.wikipedia.org/wiki/Lua_(programming_language) in a new tab, Edit (20220926): Both of these pages scroll sensibly in epiphany and MiniBrowser, so it looks more like a luakit problem. |
That's the exact sort of behavior that I have experienced. |
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. 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 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?) |
I can no longer reproduce this using the wikipedia links i mentioned above. |
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.
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 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. |
Ok, so the reason i could no longer reproduce it was that i'd screwed up some code, and thereby stopped settings loading. This kinda suggests a webkit issue, but i'll keep poking around. |
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. |
After setting |
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) |
@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 |
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.
|
@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 |
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.
This is a fresh build from git, EndeavourOS Edit: (Really) Enabling always hardware acceleration does fix github. I thought I had it on already. PEBCAK |
Well, in my hands, github works the way Lua_People does: |
It's baaaack. I have hw accel set to always, and scrolling is mostly broken on most sites. Mouse and often keyboard, too. |
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
:The text was updated successfully, but these errors were encountered: