Bug 58406 – Bringing up the context menu on a link might also follow the link

• Component: WebKit2
• Status: RESOLVED FIXED

[Brady Eidson]

Bringing up the context menu on a link might also follow the link.

This is because we bring up the context menu with "mouse press", but in some cases a "mouse release" might already be in the CoreIPC pipeline, and blindly handling that message would cause the link to be followed in the view behind the context menu.

We need to track when a context menu is showing and ignore any other pending mouse events in that state.

In radar as <rdar://problem/9029193>

[Brady Eidson]

Created attachment 89325 [details]
Patch v1

[Maciej Stachowiak]

Comment on attachment 89325 [details]
Patch v1

r=me

Is there a way to test this? EventSender.mouseDown exists...

[Brady Eidson]

The problem with layout testing it is the asynchronous nature of the race between events and the context menu.

You need to queue up an extra mouse event in the WebProcess (the mouse up) before the UIProcess actually shows the context menu.  I can't think of a way we could do this reliably - at least certainly not with the existing eventSender API in LayoutTestController.

I'm open to suggestions, but think it's prudent to land as-is in the meantime.

[Brady Eidson]

http://trac.webkit.org/changeset/83687

[Hugo Parente Lima]

This patch causes any layout test using mouse right click to fail on wk2, e.g.:

fast/events/mouse-click-events.html

Isn't the port responsible for send or not mouse events to webkit2 when the context menu is showing?

Sorry if I misunderstood something, I'm new to webkit and started to hack on qt-wk2 click events layout tests.

if this bug happen only when using async events, i.e. not using webkittestrunner, what about removing the "if (m_isShowingCon...)" only on WebPage::mouseEventSyncForTesting ?

[Hugo Parente Lima]

hmmm, I think I got the problem, forget my last comment.