[Webkit-unassigned] [Bug 100964] [Qt] Make sure that the WebView in flickable mode sends mouse events to the page rather than controlling the viewport with it

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Sergio Villar Senin <svillar at igalia.com>  2012-11-13 17:29:48 PST ---
So, in order to keep this bug rolling, I think is important to consider how events are managed in the Qt WK2 port, although I have some experience with WebKit I've just started working on WebKitQt so please correct me if I'm wrong.

Basically once we get an event from the UI there are 2 high level code paths:

1) the QtWebPageEventHandler redirects the event to the WebProcess and then WebCore processes it and informs the UIProcess using the different available clients.

2) the QtWebPageEventHandler delegates the handling of the event to one of the QtGestureRecognizers available. The gesture recognizer could then decide to send the event back to the event handler or to the viewport controller for further processing.

Jocelyn suggests to remove QQuickWebViewFlickablePrivate::handleMouseEvent. What would that mean? Right now, if using the flickable version, all the events follow path 2. This means that for example all drag actions are considered a flick. If we remove that handler, then mouse events will follow path 1, which means that WebCore will directly handle them, and will consider the previous flick gesture as a drag start event.

So if we consider the typical case of a desktop browser using the flickable WebView (which will be the only one if I understood some of you correctly) the current architecture forces us to decide between having flickable events or the classical drag events. The drag start will also collide with some other events, for example a tap and hold.

How is the port supposed to handle these conflicts?

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