Open
Bug 649770
Opened 14 years ago
Updated 2 years ago
scrolling on linux (especially smooth scrolling) catches meta keys pressed after scrolling motion is complete, causing zooming instead of scrolling
Categories
(Core :: DOM: Events, defect, P3)
Core
DOM: Events
Tracking
()
NEW
People
(Reporter: bhearsum, Unassigned)
References
Details
STR:
1) Turn on smooth scrolling (because it increases the frequency of this)
2) Start scrolling a page
3) Quickly hit "ctrl"
When I do the above, the current web page stops scrolling and starts zooming in or out, depending which way I scrolled.
I hit this a LOT, because ctrl is my meta key for switching desktops.
Comment 1•13 years ago
|
||
Just ran into the same thing myself; still an issue with Firefox 10.
OS: Linux → All
Hardware: x86_64 → All
Reporter | ||
Comment 2•13 years ago
|
||
Sadly, I think this is actually an OS problem. I ended up turning off kinetic scrolling with these instructions, and this bug went away: https://bugs.launchpad.net/utouch/+bug/728643/comments/34
Comment 3•13 years ago
|
||
Looks like this is the same as bug 720053.
Comment 5•13 years ago
|
||
I don't see any differences in XButtonEvents during regular scrolling or coasting: in both situations timestamps of release events match those of their press, and button state between release and press in inactive in both situations.
That precludes the possibility of setting a nsMouseScrollEvent::kIsMomentum flag.
A possible solution might be to not change the action of scroll events during a single "transaction". I guess our existing "transaction" detection is based on timing heuristics, maybe with pointer position and other events also considered.
Such a solution would of course not allow the user to initiate a subsequent transaction until a finite time after the previous coasting has stopped, from either friction or an explicit touch.
Component: Layout: View Rendering → DOM: Events
QA Contact: layout.view-rendering → events
Comment 6•13 years ago
|
||
The upstream bug in xf86-input-synaptics was closed as “fixed” because GTK 3 can correctly handle kinetic scrolling inertia on the client side in GtkScrolledWindow:
https://bugs.freedesktop.org/show_bug.cgi?id=38909
Comment 7•9 years ago
|
||
I know this bug hasn't seen any activity for the last three years, but it is still a problem and I'm still hoping for a fix. I may not have found them all, but this problem has been reported independently at least 12 times, in the form of the following bug reports:
#621600
#649770
#720053
#574663
#582609
#606500
#549669
#629362
#562413
#591587
#600281
#669979
Reporter | ||
Comment 8•9 years ago
|
||
(In reply to Anders Kaseorg from comment #6)
> The upstream bug in xf86-input-synaptics was closed as “fixed” because GTK 3
> can correctly handle kinetic scrolling inertia on the client side in
> GtkScrolledWindow:
> https://bugs.freedesktop.org/show_bug.cgi?id=38909
If this is truly fixed in GTK 3, this might be fixed by way of us upgrading to GTK3 in https://bugzilla.mozilla.org/show_bug.cgi?id=627699, which I know is in progress.
Comment 9•9 years ago
|
||
I am using the GTK 3 nightlies, and although pixel scrolling is very nice, this bug with inertia catching meta keys is still present. Perhaps it was accidentally reimplemented via a completely different code path.
Updated•9 years ago
|
Updated•9 years ago
|
Comment 11•9 years ago
|
||
I hit the issue a lot as well, especially because I use Ctrl a lot for other things (switching tabs or desktops).
Something most painful is that even when the scroll ended in the page (because we reached the top or the bottom), either GTK or the laptop is still sending the wheel events even they have no action, so when we hit ctrl it still zooms in/out when we didn't really knew about it. We need to forcefully wait some time until we're sure the kinetic scrolling is stopped.
Moreover if the kinetic scrolling is still happening while we change a tab (ctrl + pagedown/up), it also zooms in/out the new tab !!
Of course I'm sure it's not a Firefox bug, but maybe we can make the issue less visible ? For example we could detect if the scroll behavior occured on the previous tab and ignore it on the current tab ?
(note I'm using GTK3 builds now but the issue didn't disappear).
Updated•9 years ago
|
Comment 12•7 years ago
|
||
Hi, Just in case someone comes around this bug,
I am on latest version of Firefox i.e. 59.0-2
Operating System - Arch Linux
WM - i3
Laptop model - Lenovo Y50-70
This is still a problem in Firefox.
Steps to reproduce the issue.
1. Turn on Smooth scrolling.
2. Start scrolling on a long page(Long page part is unnecessary).
3. Remove your fingers from trackpad and press Ctrl.
Expected behavior, Nothing should happen on pressing Ctrl.
Actual Behaviour, It zooms in or out depending on if was scrolling up or down.
Perhaps, Zoom In/Out shortcuts shouldn't work if there is no active finger on the trackpad.
Updated•6 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•