Bug 656977

Summary: keyboard <-> "scrollwheel" events seem out of order
Product: [Fedora] Fedora Reporter: Nils Philippsen <nphilipp>
Component: xorg-x11-drv-synapticsAssignee: Peter Hutterer <peter.hutterer>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: peter.hutterer
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-26 06:09:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nils Philippsen 2010-11-24 16:01:22 UTC
Description of problem:
Web browsers (or other applications that use Ctrl+Scrollwheel-Motion) behave strangely:

Since a while, my synaptics-driven "AlpsPS/2 ALPS DualPoint TouchPad" has "coasting" enabled where you give the emulated scroll wheel a "kick" with your fingers on the right-hand (or bottom-most) side of the touchpad and it continues e.g. scrolling for a while.

Unfortunately, X11 seems to think that the event(s) are still happening after my fingers long left the touch pad, i.e. when I now press Ctrl (e.g. to Ctrl-Click a link to open it up in a new tab), the zoom factor of the page gets changed (what would happen if I pressed Ctrl actually while using the scrollwheel emulation).

Version-Release number of selected component (if applicable):
xorg-x11-drv-synaptics-1.3.0-1.fc14.x86_64

How reproducible:
Easily

Steps to Reproduce:
1. open a long web page (e.g. slashdot) in a browser (e.g. firefox or chromium)
2. give the "scroll wheel" a kick so that it continues "coasting" for a short while
3. after the fingers have left the touch pad, but while the web page still scrolls on ("coasts"), press "Ctrl"
  
Actual results:
Zoom level of the page changes.

Expected results:
Zoom level doesn't change.

Comment 1 Peter Hutterer 2010-11-30 02:03:08 UTC
can you reproduce this with xev? I wonder if the expensive zoom operation is simply the problem here. so while firefox is repainting in various zoom stages, some events are queued up (including the ctrl) one and once the events are being processed, the modifier state has changed.
so when firefox finally gets to process the events that originated several seconds ago, it interprets them as zoom.


you should also be able to verify this with a very simple page that's less expensive to zoom

Comment 2 Peter Hutterer 2012-06-26 06:09:36 UTC
This bug was filed against Fedora 14 which is now EOL. Please re-open this bug if you still experience this issue with one of the currently suppported versions of Fedora. Don't forget to update the version field if you do so.