Bug 120458 – [GTK][WTR] A ContextMenu open with eventSender.contextClick leaves next tests's mouse events not working

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

[Simon Pena]

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 :)

[Simon Pena]

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.

[Simon Pena]

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

[Martin Robinson]

Comment on attachment 211787 [details]
Patch

Perhaps you could avoid private API by using gtk_menu_popdown?

[Carlos Garcia Campos]

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

[Simon Pena]

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!

[Michael Catanzaro]

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?

[Simon Pena]

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

[Simon Pena]

This is no longer happening in https://commits.webkit.org/290939@main, and has probably been fixed for a long time. Closing