Bug 80029 - [Qt][WK2] Make the interaction with the Flickable work on the N9
Summary: [Qt][WK2] Make the interaction with the Flickable work on the N9
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All Linux
: P2 Normal
Assignee: Andras Becsi
URL:
Keywords:
Depends on:
Blocks: 79119
  Show dependency treegraph
 
Reported: 2012-03-01 08:03 PST by Andras Becsi
Modified: 2012-03-01 13:52 PST (History)
3 users (show)

See Also:


Attachments
proposed patch (4.74 KB, patch)
2012-03-01 08:07 PST, Andras Becsi
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andras Becsi 2012-03-01 08:03:49 PST
Since the WebView accepts all the received touch events, the event to control the Flickable does not get translated to a mouse event on the N9.
Do the touch->mouse conversion in QtFlickProvider instead of relying on Qt to translate the unhandled touch events.
Comment 1 Andras Becsi 2012-03-01 08:07:38 PST
Created attachment 129706 [details]
proposed patch
Comment 2 Simon Hausmann 2012-03-01 08:16:18 PST
Comment on attachment 129706 [details]
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=129706&action=review

> Source/WebKit2/UIProcess/qt/QtFlickProvider.cpp:156
> +    QCoreApplication::sendEvent(m_flickable->canvas(), &mouseEvent);

This is a bit unfortunately, it sounds like we need a function in QQuickCanvas to send an event to a specific item, in order to ensure delivery. Couldn't theoretically the event end up in a different item if it happens to be "on top"? (of course we shouldn't have received the touch event in the first place then...)

Anyway, this is an improvement and clearly makes the code more robust (less relying on magic event conversion elsewhere).
Comment 3 Andras Becsi 2012-03-01 08:38:34 PST
(In reply to comment #2)

Thanks for the review, Simon.

> (From update of attachment 129706 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=129706&action=review
> 
> > Source/WebKit2/UIProcess/qt/QtFlickProvider.cpp:156
> > +    QCoreApplication::sendEvent(m_flickable->canvas(), &mouseEvent);
> 
> This is a bit unfortunately, it sounds like we need a function in QQuickCanvas to send an event to a specific item, in order to ensure delivery. Couldn't theoretically the event end up in a different item if it happens to be "on top"? (of course we shouldn't have received the touch event in the first place then...)
> 
We could theoretically send the event directly to the Flickable with QQuickCanvas::sendEvent, but since this code path goes to Flickable::handleMouseFooEvent the item does not grab the mouse and this results in strange behavior for gestures which move out of the viewport, which is of course only an issue on desktop.
I hope we can leave behind these issues with the touch related changes in Qt5 suggested by Shawn.
Comment 4 WebKit Review Bot 2012-03-01 10:26:04 PST
Comment on attachment 129706 [details]
proposed patch

Rejecting attachment 129706 [details] from commit-queue.

Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 1

ERROR: /mnt/git/webkit-commit-queue/ChangeLog neither lists a valid reviewer nor contains the string "Unreviewed" or "Rubber stamp" (case insensitive).

Full output: http://queues.webkit.org/results/11776526
Comment 5 Andras Becsi 2012-03-01 13:51:53 PST
Comment on attachment 129706 [details]
proposed patch

Clearing flags on attachment: 129706

Committed r109415: <http://trac.webkit.org/changeset/109415>
Comment 6 Andras Becsi 2012-03-01 13:52:04 PST
All reviewed patches have been landed.  Closing bug.