[Webkit-unassigned] [Bug 92394] [Qt] Fix axis locking when panning on N9

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=92394





--- Comment #6 from Andras Becsi <abecsi at webkit.org>  2012-07-30 04:16:19 PST ---
(From update of attachment 155079)
View in context: https://bugs.webkit.org/attachment.cgi?id=155079&action=review

The patch looks better now but I still have some concerns. It would also be good to have a manual test for this in ManualTests/qt if possible, which triggers the issues on the N9.

> Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:219
> +        // Use screenPos as it'll be used to create synthetic MouseEvents
> +        setReferencePosition(initialPoint.screenPos());

I do not really understand this part. Why do we need the screenPos for the reference position when the pan gesture recognizer uses touchPoint.pos() when calling panGestureRequestUpdate which position is then used for the MouseEvent? The incoming touch position is in viewport coordinates and is the same local position which is then used by the pan gesture recognizer to notify the Flickable. With this change we end up with one component of the position in local coordinates and the other in screen coordinates when locking.
I might miss something but the issue you try to fix here seems rather to be an orientation bug on the N9 where the touch coordinates do not get properly translated to portrait mode in the canvas.

> Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:-1874
> -    Q_D(QQuickWebView);
> -    d->axisLocker.setReferencePosition(position);

The intention of setting the reference point when the notification comes from the pan gesture recognizer (after coming back from the web process) was that some events might be handled by the page and in that case the event is ignored by the event handler. So if the reference position is set on the incoming side we might end up with a wrong reference position in cases when that event is ignored but subsequent events get through to the Flickable without triggering a reset of the lock. Though it might not be possible to produce a page that triggers errors related to this behaviour.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.