After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703919 - Arrows indicating direction to swipe are backwards with "content sticks to fingers" enabled
Arrows indicating direction to swipe are backwards with "content sticks to fi...
Status: RESOLVED DUPLICATE of bug 704050
Product: gnome-shell
Classification: Core
Component: lock-screen
3.8.x
Other Linux
: Normal minor
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-07-10 06:20 UTC by David Strauss
Modified: 2013-07-14 13:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Strauss 2013-07-10 06:20:59 UTC
The arrows and animation on the lock screen assume a scrolling-like action in the direction *opposite* of "content sticks to fingers."

What happens:
 1. I enable "content sticks to fingers."
 2. I get the lock screen with the suggestive arrows pointing upward.
 3. I swipe upwards, and nothing happens.
 4. I swipe downwards (just in an effort to try other things), and the clock screen animates in the opposite direction of my downward swipe.

What should happen:
 1. I swipe in the direction of the arrows, and the clock screen animates away in the direction of my swipe.

I don't think it matters whether the fix switches the direction of arrows/animation or the direction of the expected swipe when I enable "content sticks to fingers." I just want them to match.
Comment 1 Giovanni Campagna 2013-07-14 13:00:13 UTC
The arrow is correct, you're supposed to lift the shield physically up. So what we need to is to reverse the scrolling direction when natural scroll is enabled.

Marking duplicate of a newer bug which has a patch.

Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 704050 ***