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

[Carlos Garcia Campos]

El jue, 07-01-2016 a las 15:24 +0000, Mario Sanchez Prada escribió:
> 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?

Yes. Imagine the web view handles a key combination, if we propagate
the events always, if the parent window also handles that combination,
both things will happen. Same happens with button press, some websites
handle right click to show their own context menu, if we propagate the
event we will end up with both the website context menu and the
application context menu in that particular case. That's why we changed
it, and unfortunately I don't see a better solution, not propagating
events is the less problematic solution. For keyevents we
have doneWithKeyEvent in PageClient, so that we know if the event was
handled by the web process or not, and if not we re-emit it to
propagate it. You could add something similar
in WebPageProxy::didReceiveEvent() for mouse events. Maybe we could
generalize it and use a single notification doneWithEvent().

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

> Thanks,
> Mario
> 
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20160108/c59c3c8e/attachment.sig>