[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 #4 from Jocelyn Turcotte <jocelyn.turcotte at digia.com>  2012-11-14 01:37:21 PST ---
(In reply to comment #3)
> 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.

The way I think it works right now (I'm no expert on this either) is that those two code paths are actually sequential.
Both touch and mouse events will first got through the web process (WebPage::touchEvent), and if the event wasn't handled by the page, return it to the UI process (WebPageProxy::didReceiveEvent) which will then give it back to QtWebPageEventHandler through PageClient::doneWithTouchEvent.

For mouse events however, WebPageProxy::didReceiveEvent doesn't push them back to the higher layers.

We might have to add shortcuts at some point to prevent a busy web process from delaying viewport interaction by sending events directly to the event handler (e.g. if we know the page doesn't have touch handlers at this position), but the logic should still apply.

> 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?

The way I see it is that the WebView is only behaving as a flickable if you interact with it using touch events. To scroll the view using a mouse there are still the mouse wheel and scrollbars. Nobody (I assume) wants to flick using a mouse anyway.
That means that there would be no way of drag'n dropping using a touch device.

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