When I was investigating bug #120401, I noticed that after editing/selection/empty-cell-right-click.html was run, next tests would stop passing. Once I removed it from the lists, the tests would behave correctly (their exact behaviour depending on whether the patch fixing the ClickCounter state was applied or not). I then debugged a bit more and found that when the ContextMenu is shown, it seems to swallow all next mouse events: that's the reason for all tests running after it being flaky. In order to confirm this, I added a call in WebPageProxy to hide the context menu with m_activeContextMenu->hideContextMenu() whenever a test finishes. Again, as in bug #120401, I'm not sure on the right approach for this, so I would appreciate comments :)
For completeness, since I just said that I added the call but didn't mention what happened afterwards: hiding the context menu gets all mouse events processing again.
Created attachment 211787 [details] Patch When resetting the WebView to a consistent state, hide the active context menu, if any. This patch depends on bug #120401
Comment on attachment 211787 [details] Patch Perhaps you could avoid private API by using gtk_menu_popdown?
Mac runs a nested main loop for context menus, I wonder how they finish that loop then. We should try to use the same solution that other ports if possible before trying our own thing
Anders & Sam, I see you were working in: Source/WebKit2/UIProcess/mac/WebContextMenuProxyMac.mm, where WebContextMenuProxyMac::showContextMenu calls WKPopupContextMenu and later [m_popup.get() dismissPopUp]; In GTK, when creating events with the EventSenderProxy in WebKitTestRunner, our calls to contextClick show the context menu, and after that it remains open, swallowing further mouse events. This patch manually closes the popup menu, but as Carlos says in comment #4, we would like to know how you deal/dealt with this in the Mac port. Thanks!
Comment on attachment 211787 [details] Patch I'm resetting the r? flag on this, since the patch is quite old. We have no flakiness expectations for this test, so I presume this problem has since been solved and the bug is obsolete? Is this still causing any test failures?
(In reply to comment #6) > Comment on attachment 211787 [details] > Patch > > I'm resetting the r? flag on this, since the patch is quite old. > > We have no flakiness expectations for this test, so I presume this problem > has since been solved and the bug is obsolete? Is this still causing any > test failures? Hi Michael, I have been quite disconnected from this lately, so I can't tell if this is still an issue. (To be honest, I thought I had cleared r? from all my bugs, I'm surprised this one still had it. Sorry about that)