4 ms·

Fun fact. In Ghostty and (some) other GTK apps, if your mouse leaves the window, the first scroll click after re-entering the window is ignored. This is due to

Fun fact. In Ghostty and (some) other GTK apps, if your mouse leaves the window, the first scroll click after re-entering the window is ignored. This is due to an ancient bug first identified in 2015. https://bugzilla.gnome.org/show_bug.cgi?id=750994 https://bugzilla.gnome.org/show_bug.cgi?id=750994 There are no plans for a fix. The maintainer recommends waiting for Wayland.

pilif 1y ago
Reading the report you reference and other issues linked there, I would say that multiple attempts were made to fix it, all of which unfortunately required some heuristics and all of which have broken something else that was deemed worse. It seems to boil down to an issue in the underlying X11 machinery and it would need to be fixed there first to build a basis on which proper fixes can be implemented. Given that X11 is in maintenance mode (and as its fans keep saying: It works perfectly fine and doesn't need any more work done on it), it's not likely that's happening. So, yes, given that information (and I just arrived at that bug report through your post), I would indeed say that waiting for Wayland is the only option they have. All other attempts ended up causing worse issues.
- account42 1y ago
  Other toolkits don't seem to have this issue on X11.
  - pilif 1y ago
    those toolkits do not support smooth scrolling. The issue comes from XInput2 (https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.t...) So I guess the "fix" would be to have two completely separate input handlers on X11, one of which supporting smooth scrolling and multitouch, the other not and then offering users a toggle in the style of [ ] do not ignore the first scroll input after focus loss, but disable smooth scrolling and multitouch Plus handling all the potential issues by having two separate input handlers. That's asking a bit much for this particular issue und greatly smells like a case of XKCD 1172
jeroenhd 1y ago
From what I can tell, that's an XInput2 bug, not a GTK bug. I suppose GTK can try to implement workarounds like the Chromium heuristic (https://issues.chromium.org/issues/41243294 https://issues.chromium.org/issues/41243294) but the problem lies upstream.

pilif 1y ago

Reading the report you reference and other issues linked there, I would say that multiple attempts were made to fix it, all of which unfortunately required some heuristics and all of which have broken something else that was deemed worse. It seems to boil down to an issue in the underlying X11 machinery and it would need to be fixed there first to build a basis on which proper fixes can be implemented. Given that X11 is in maintenance mode (and as its fans keep saying: It works perfectly fine and doesn't need any more work done on it), it's not likely that's happening. So, yes, given that information (and I just arrived at that bug report through your post), I would indeed say that waiting for Wayland is the only option they have. All other attempts ended up causing worse issues.

account42 1y ago
Other toolkits don't seem to have this issue on X11.
- pilif 1y ago
  those toolkits do not support smooth scrolling. The issue comes from XInput2 (https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.t...) So I guess the "fix" would be to have two completely separate input handlers on X11, one of which supporting smooth scrolling and multitouch, the other not and then offering users a toggle in the style of [ ] do not ignore the first scroll input after focus loss, but disable smooth scrolling and multitouch Plus handling all the potential issues by having two separate input handlers. That's asking a bit much for this particular issue und greatly smells like a case of XKCD 1172

jeroenhd 1y ago

From what I can tell, that's an XInput2 bug, not a GTK bug. I suppose GTK can try to implement workarounds like the Chromium heuristic (https://issues.chromium.org/issues/41243294 https://issues.chromium.org/issues/41243294) but the problem lies upstream.