Bug 185072 – [GTK] Some event tests failing after r230817

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Claudio Saavedra]

+fast/events/mouse-click-events.html [ Failure ]
+fast/events/context-activated-by-key-event.html [ Failure ]
+fast/events/mouse-cursor-change.html [ Failure ]

These started failing in the GTK+ port after r230743 was landed, then started working again when it was reverted, and started failing again when r230817 landed. Carlos reviewed that patch so I'm adding him in CC.

[Carlos Garcia Campos]

I'll investigate it, thanks!

[Carlos Garcia Campos]

They fail on x11, but not in wayland.

[Carlos Garcia Campos]

Ok, I know what's going on. Tests are finishing before all events are processed and logged. r230817 changed the behavior of mouse events and made it slower too, specially in the case of X11 that generates several crossing events (handled by WebKit as mouse move events). Before r230817 mouse down/up events were always sent to the web process immediately, now we wait for the response of all the previous mouse events sent to the web process. Also before r230817, when several mouse move events were received by the web view, we discarded the ones in the middle of the sequence, now we are always sending all of them and waiting for their responses. In the case of mouse events we don't really need to wait for previous events to send new ones.

[Carlos Garcia Campos]

One problem we have in X11 is that mouse events are not always processed in the order they are sent. The main difference is that when the context menu is shown, a crossing event is generated in the web view, a leave happens in the view and enter in the context menu. That crossing is processed during the press:

1- ButtonPress is received in the web process
2- handleContextMenuEvent()
3- MouseMove is received in the web process
4- DidReceiveEvent for the MouseMove is sent to the UI process
5- DidReceiveEvent for the ButtonPress is sent to the Ui process

This breaks the queue model used in the UI process.

[Carlos Garcia Campos]

The problem with messages handled in different order is because WTR uses fully sync mode for testing for their events, but crossing events are not generated by WTr, but by the xserver (or GTK+, I'm not sure). That confuses everything and sometimes a move after a press or release can be processed before the press or release. I think we can simply ignore crossing events during testing, since WTR never generates them.

[Carlos Garcia Campos]

Created attachment 339401 [details]
Patch

It seems those crossing events were confusing other tests.

[Carlos Garcia Campos]

Created attachment 339402 [details]
Patch

Now the right patch

[EWS Watchlist]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

[Michael Catanzaro]

Comment on attachment 339402 [details]
Patch

Not great....

[Blaze Burg]

Comment on attachment 339402 [details]
Patch

Well, I certainly didn't expect that the WM would reorder mouse moves and mouse downs... :|

[Carlos Garcia Campos]

(In reply to Brian Burg from comment #10)
> Comment on attachment 339402 [details]
> Patch
> 
> Well, I certainly didn't expect that the WM would reorder mouse moves and
> mouse downs... :|

Sure, the problem is that all events generated by WTR are handled synchronously, but crossing events generated by the xserver/gtk are handled normally. It took me a while to understand was going on.

[Carlos Garcia Campos]

Committed r231349: <https://trac.webkit.org/changeset/231349>