Mir

Scrolling is sometimes going in the other direction than wanted

Bug #1418213 reported by taiebot65
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mir
Confirmed
Medium
Unassigned
mir (Ubuntu)
Confirmed
Medium
Unassigned
unity8 (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Nexus 4 Mako vivid. r.89 but notice since a year ago.

This happens in every app, dash or things where you can scroll down or up.
Not sure if its related to the sensitivity of the screen.

Tags: input mako nexus4
tags: added: mako
tags: added: input
tags: added: nexus4
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Confirmed on mako today. Although the bug is very hard to reproduce on demand.

Changed in mir:
status: New → Confirmed
Changed in unity8 (Ubuntu):
status: New → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I think this might be related to the QML scroll logic in Unity8. It's probably not a Mir bug.

kevin gunn (kgunn72)
Changed in unity8 (Ubuntu):
status: Confirmed → In Progress
Changed in mir:
status: Confirmed → In Progress
status: In Progress → New
status: New → Confirmed
Changed in unity8 (Ubuntu):
status: In Progress → Confirmed
Changed in mir:
importance: Undecided → Medium
Changed in unity8 (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Albert Astals Cid (aacid) wrote :

There's no "QML scroll logic in Unity8"

Revision history for this message
Albert Astals Cid (aacid) wrote :

This probably has to do with what we already discussed ages ago in a separate bug, Mir or the hardware is sending wrong fake positions well in advance of where the finger actually is and then on release it corrects those doing a swipe back that makes Qt Quick think you actually want to swipe back.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Comment #4: That is Android's touch prediction logic (and the relevant un-prediction) which is very small -- never more than half a frame predicted ahead. So the un-prediction at the end of a gesture is at most one touch event. If Unity8 is doing fling velocity calculation on a granularity of one event then it's probably Unity8 that needs fixing more. That would also explain why Unity8 randomly gets the fling velocity wrong (my finger is moving slowly but the scroll is flung quickly on release).

Comment #3: What about this?
/usr/share/unity8/Components/ScrollCalculator.qml
/usr/share/unity8/Panel/PanelVelocityCalculator.qml
etc.

Revision history for this message
Albert Astals Cid (aacid) wrote :

ScrollCalculator and PanelVelocityCalculator are using only on the indicators panel and since reporter says "This happens in every app, dash" i don't think they're related to this at all.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Well Qt then. This bug combined with a similar bug where the scroll goes overly fast on finger release suggests we're estimating fling velocity on finger release based on too few recent touch events.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Retested the latest devel-proposed image today (includes Mir 0.18.0) and this bug is still present.

Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.