[webkit-gtk] WebView avoiding propagation of some GtkWidget signals

[philip.chimento at gmail.com]

On Thu, Jan 7, 2016 at 11:03 PM Carlos Garcia Campos <cgarcia at igalia.com>
wrote:

> El jue, 07-01-2016 a las 15:24 +0000, Mario Sanchez Prada escribió:
> > On 07/01/16 07:19, Carlos Garcia Campos wrote:
> [...]
> > I can see that would be a redefinition of the "event was handled by
> > that
> > handler or now" concept, but perhaps it's good enough for this
> > purpose of
> > not stopping the propagation of the event while not requiring
> > synchrony?
> >
> > Beware, I might be saying something really silly, but I had to ask.
> >
> > > > For the record, this is a problem in an app we have as we need to
> > > > handle the
> > > > "motion-notify-event" signal from the webview's parent GtkWidget,
> > > > which is
> > > > not possible atm due to [1], and not sure a workaround would make
> > > > sense.
> > >
> > > Are you using a widget derived from WebKitWebView and handling the
> > > event using the default handler? Because if you connect with
> > > g_signal_connect you should get the events, since in that case the
> > > callback is called before the default handler (motion-notify-event
> > > is
> > > a G_SIGNAL_RUN_LAST).
> >
> > Yes, connecting to the WebView with g_signal_connect() is not the
> > issue (I
> > can do it and get those events without problems), but the fact that
> > connecting to the same signal from the container widget (whose
> > GdkWindow has
> > the GDK_POINTER_MOTION_MASK mask set) does not get the callback
> > called.
> >
> > That's the problem I'm trying to solve or workaround here, but from
> > your
> > words I'm not entirely sure there's a good solution at the level of
> > WK, so
> > perhaps we should start looking into dealing with the signal emission
> > from
> > the WebView itself instead, not sure if that's possible though.
> >
> > In any case, and regardless of this, I think it would be interesting
> > to have
> > the WebView widget behaving like a normal GtkWidget and not
> > swallowing those
> > events, so any info/advice on this would still be much appreciated.
>
> A normal widget propagates the events when not handled, and stop
> propagation when handled. We assume we handle all the events, because
> we don't know it in advance. The only solution I can think of is re-
> injecting events once we know they hasn't been handled. Or maybe for
> some kind of events like mouse move there's no problem at all in always
> propagate them.
>

I think it makes a lot of sense, what you say above about always returning
FALSE specifically for mouse move events. With a click, I can see why the
WebView should swallow it; a click is always intended for one target. But
with a mouse movement, the mouse pointer is _there_ in the new location
whether a target reacts to it or not.

So even if you are drawing on a <canvas>, for example, that handles the
mouse move events, why shouldn't GTK be able to handle them as well?

Regards,
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20160108/5e80cb8c/attachment.html>