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