The custom context menu is shown on "mouseup", which is fired always without any problems.

Tested the issue on windows 7 using chrome M60 #60.0.3112.78 and canary M62 #62.0.3172.0 and followed steps mentioned in comment #0 and observed similar behavior in firefox and chrome.

Attached screencast for reference.

@ivan.kuckir-- Could you please check attached screencast and confirm us if we have missed any steps in reproducing the issue and help us by providing the screencast of the issue.

Thanks!

Deleted: 750492.mp4 1.6 MB

	750492.mp4 1.6 MB View Download

Hi, can you try to right-click at different positions? Do you have a zoom 125%? Here is my screen capture: https://drive.google.com/file/d/0BxArubd1dklJcUVyOTk1Q3hNYWc/view

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on windows 7 using chrome M60 #60.0.3112.78 and it got fixed in latest chrome dev and canary channels.

Using the per-revision bisect providing the reverse bisect results,
Good build: 61.0.3138.0(Revision: 481386).
Bad build: 61.0.3136.0 (Revision: 480665).

You are probably looking for a change made after 481207 (known good), but no later than 481208 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspectas some perf builds might get missing due to failure.

 https://chromium.googlesource.com/chromium/src/+log/148c2697ed43abbc96e517b0c65517ebcef171b7..4cef659a8009c5cb4f5708336ae37654d23653b3

From the CL above, assigning the issue to the concern owner 

@Dave Tapuska- Could you please merge the fix to M60.

Review URL : https://chromium.googlesource.com/chromium/src/+/4cef659a8009c5cb4f5708336ae37654d23653b3

Note : Issue is seen only in windows.

Thanks!

I'm able to reproduce it even in Canary 62.0.3173.2.

It seems your context menu listener on the page happens on the div.pbody class.

The problem is the targeting of the context menu event. You seem to be building your own context menu on the mouseup which occurs before the context menu. So when the context menu is then dispatched it sometimes (depends on timing) ends up getting passed to the menu.

If I listen to monitorEvents(document, "contextmenu") in devtools it shows me the event always. 

I suggest that you instead build your own context menu always in the context menu call and not the mouseup.

"ends up getting passed to the menu" - that is interesting, I never thought about it.

So "contextmenu" should occur on an element E, only if right mousedown and right mouseup occured on E ... You say, that my mouseup occured on a different element, and that is why "contextmenu" did not occur on the original element. But in that case, the default browser context menu should not be shown either ... am I right?

BTW. showing a custom context menu on "contextmenu" caused huge problems in Chrome OS ... I thought that this bug would be easier to fix.

Each event will do a hit test and be dispatched to whatever is under it. If you move something in between (as you are doing) between the events the event will be dispatched there. I'm not certain why it doesn't happen always but something in the code path must be forcing a layout. 

If say you put layout inducing code in one of your event handlers (say the mouseup) then it probably would always happen. (Note that querying layout inducing properties is never good; I'm just figuring why it is occurring).

Oh and it seems that you are serving up different files based on user agent already. The file on a Chrome Linux pp.js file is different than the one served up for Chrome Windows. So I really don't know what the differences are

I am sorry, I am working on my editor and updating it every moment. But I have not changed the behavior of a context menu.

So I guess it is not a bug. I will listen to "contextmenu" event instead and report a new Chrome OS bug. You can close this now.