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

[Mario Sanchez Prada]

Hi Carlos,

Thanks for the great feedback, as usual. See my comments below...

On 08/01/16 07:02, Carlos Garcia Campos wrote:
> [...]
> 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.

I see, thanks for the extended version of the explanation, that makes more
sense to me now.

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

Thanks for the hint. I think I'll take a look to that, as I still think that
looking for a way to have these events being propagated when not handled is
a goal worth pursuing, at least for the motion-notify-event.

> [...]
> 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 trying to re-emit the event once we know it has not been handled
might actually be a good solution here, as there's probably no point on
doing that when the web page has actually handled it first.

I did a quick test now putting some prints in WebPage.cpp:handleMouseEvent
to get an idea of when those motion events got handled by the webprocess and
confirmed that in the normal case (just moving the mouse around) they are
not handled at all (thus we should re-emit the event) while in other cases,
such as painting in an HTML5 canvas[1], those events are actually handled
and so we should not re-emit.

Again, thanks for the tip, I'll work on this asap.

Mario

[1] https://dev.opera.com/articles/html5-canvas-painting/example-5.html