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

[Mario Sanchez Prada]

On 07/01/16 07:19, Carlos Garcia Campos wrote:
> [...]
>> Carlos, Gustavo or anyone else... could you drop some light on this,
>> please?
> 
> The thing is that in the GTK+ events model, everything is synchronous,
> so the event handlers return TRUE/FALSE dependening on whether the
> event was handled by that handler or not. In WebKit2 that happens
> asynchronously, we need to send the events to the web process that will
> handled them, so when we return the events handler in the UI process we
> still don't know if the web process will handle the event or not.

That makes sense, thanks for the clarification.

> In
> the case of key events we save the event, and when the web process
> replies we re-emit the event if it was not handled by the web process.
> This is also problematic, because you could see the events twice. The
> easiest solution would be to make all event handlers use sync messages,
> but that would affect the performance I'm afraid.

Yes, I can imagine lots and lots of IPC happening whenever the user moves
the mouse over the webview, and how that could be an issue if that IPC is
synchronous...

Now I have another question, though: would it be wrong to return FALSE just
after sending the message to be handled by the web process, without waiting
for the response?

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.

Thanks,
Mario