|Summary:||[GTK] Some event tests failing after r230817|
|Product:||WebKit||Reporter:||Claudio Saavedra <csaavedra>|
|Severity:||Normal||CC:||bburg, berto, bugs-noreply, cgarcia, ews, gns, mcatanzaro|
Description Claudio Saavedra 2018-04-27 04:43:44 PDT
+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.
Comment 1 Carlos Garcia Campos 2018-04-27 05:00:16 PDT
I'll investigate it, thanks!
Comment 2 Carlos Garcia Campos 2018-04-30 02:23:07 PDT
They fail on x11, but not in wayland.
Comment 3 Carlos Garcia Campos 2018-04-30 05:02:33 PDT
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.
Comment 4 Carlos Garcia Campos 2018-04-30 07:04:38 PDT
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.
Comment 5 Carlos Garcia Campos 2018-05-03 03:10:15 PDT
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.
Comment 6 Carlos Garcia Campos 2018-05-03 04:11:40 PDT
Created attachment 339401 [details] Patch It seems those crossing events were confusing other tests.
Comment 7 Carlos Garcia Campos 2018-05-03 04:16:30 PDT
Created attachment 339402 [details] Patch Now the right patch
Comment 8 Build Bot 2018-05-03 04:18:09 PDT
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
Comment 9 Michael Catanzaro 2018-05-03 08:58:16 PDT
Comment on attachment 339402 [details] Patch Not great....
Comment 10 Brian Burg 2018-05-03 09:30:13 PDT
Comment on attachment 339402 [details] Patch Well, I certainly didn't expect that the WM would reorder mouse moves and mouse downs... :|
Comment 11 Carlos Garcia Campos 2018-05-04 03:08:09 PDT
(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.