[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 #8 from Andras Becsi <abecsi at webkit.org>  2012-11-19 03:54:29 PST ---
(In reply to comment #4)
> (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.

Exactly, at this point the event is processed by the gesture recognizers and depending on the gesture we either control the flickable (QQuickWebView::handleFlickableMouse*) for pan gestures or we synthesize a tap or act on a double tap or scale the page item if the gesture was a pinch.

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

Yes, I think the shortcutting is still something we want to do later, because as web pages have more and more event handlers our interaction might end up being sluggish which we do not want.

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

Drag&drop on a touch device should in my opinion be implemented with a tap-and-hold gesture which would open a context menu and where applicable would offer drag&drop.
I do not think that having this feature now is of high priority for us, though, since the tap-and-hold logic for context menus needs to be implemented first which depends on client side QML and is thus tied to the Desktop/Touch Components projects.

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