[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 bugzilla-daemon at webkit.org
Wed Nov 14 13:02:41 PST 2012


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





--- Comment #5 from Sergio Villar Senin <svillar at igalia.com>  2012-11-14 13:04: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.
> 
> For mouse events however, WebPageProxy::didReceiveEvent doesn't push them back to the higher layers.

Hmm taking a look at the code, the flickable private object redirects all mouse events to QtWebPageEventHandler::handleInputEvent. This means that the event will be handled by the gesture recognizers in the UI side and nothing will be send to the WebProcess, or am I wrong? As you said if we remove that handler then all the events will be then sent to the WebProcess directly.

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

Ok that looks like a good trade-off. I am not sure that nobody wants to flick using a mouse though. For example I was thinking about interfaces like the Wii, were you have a pointer device that effectively acts as a mouse, but IIRC the Opera browser it has does some kind of panning (flick) instead of scrolling. The hybrid devices mentioned somewhere else could be another example.

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



More information about the webkit-unassigned mailing list