<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jan 7, 2016 at 11:03 PM Carlos Garcia Campos &lt;<a href="mailto:cgarcia@igalia.com">cgarcia@igalia.com</a>&gt; 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>
&gt; On 07/01/16 07:19, Carlos Garcia Campos wrote:<br>[...]<br>
&gt; I can see that would be a redefinition of the &quot;event was handled by<br>
&gt; that<br>
&gt; handler or now&quot; concept, but perhaps it&#39;s good enough for this<br>
&gt; purpose of<br>
&gt; not stopping the propagation of the event while not requiring<br>
&gt; synchrony?<br>
&gt;<br>
&gt; Beware, I might be saying something really silly, but I had to ask.<br>
&gt;<br>
&gt; &gt; &gt; For the record, this is a problem in an app we have as we need to<br>
&gt; &gt; &gt; handle the<br>
&gt; &gt; &gt; &quot;motion-notify-event&quot; signal from the webview&#39;s parent GtkWidget,<br>
&gt; &gt; &gt; which is<br>
&gt; &gt; &gt; not possible atm due to [1], and not sure a workaround would make<br>
&gt; &gt; &gt; sense.<br>
&gt; &gt;<br>
&gt; &gt; Are you using a widget derived from WebKitWebView and handling the<br>
&gt; &gt; event using the default handler? Because if you connect with<br>
&gt; &gt; g_signal_connect you should get the events, since in that case the<br>
&gt; &gt; callback is called before the default handler (motion-notify-event<br>
&gt; &gt; is<br>
&gt; &gt; a G_SIGNAL_RUN_LAST).<br>
&gt;<br>
&gt; Yes, connecting to the WebView with g_signal_connect() is not the<br>
&gt; issue (I<br>
&gt; can do it and get those events without problems), but the fact that<br>
&gt; connecting to the same signal from the container widget (whose<br>
&gt; GdkWindow has<br>
&gt; the GDK_POINTER_MOTION_MASK mask set) does not get the callback<br>
&gt; called.<br>
&gt;<br>
&gt; That&#39;s the problem I&#39;m trying to solve or workaround here, but from<br>
&gt; your<br>
&gt; words I&#39;m not entirely sure there&#39;s a good solution at the level of<br>
&gt; WK, so<br>
&gt; perhaps we should start looking into dealing with the signal emission<br>
&gt; from<br>
&gt; the WebView itself instead, not sure if that&#39;s possible though.<br>
&gt;<br>
&gt; In any case, and regardless of this, I think it would be interesting<br>
&gt; to have<br>
&gt; the WebView widget behaving like a normal GtkWidget and not<br>
&gt; swallowing those<br>
&gt; 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&#39;t know it in advance. The only solution I can think of is re-<br>
injecting events once we know they hasn&#39;t been handled. Or maybe for<br>
some kind of events like mouse move there&#39;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 &lt;canvas&gt;, for example, that handles the mouse move events, why shouldn&#39;t GTK be able to handle them as well?</div><div><br></div><div>Regards,</div><div>Philip</div><div>¬†<br></div></div></div>