Using the per-revision bisect providing the bisect results,
Good build: 54.0.2823.0 (Revision: 410278).
Bad build: 54.0.2824.0 (Revision: 410520).

You are probably looking for a change made after 410485 (known good), but no later than 410488 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/a5191dca2b309396a7743816917f19d037ebc39a..ac8f7479131ebdf1ddc207a49e486ed300769070

Suspecting Commit# 4d87f4e9da90c5fdc94ad48cd6b5c888ef8bd896
Suspecting Review URL# https://codereview.chromium.org/2162143002

@dtapuska -- Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.
Thank You.

This is definitely caused by my change to the input_router_impl which causes more mouse move events to be in flight than just one. This was necessary to solve some input performance scenarios with gaming.

Since Flash actually populates that context menu and controls it I'm hoping someone on their end can help debug this. I'm wondering if they are going something special with mouse move events and having more than one in flight now is causing them some grief.

laforge@ can you add the appropriate people from adobe who can comment on this issue so that we can get it resolved?

So from what I can figure out is that Flash enters an InternalRun message loop (https://cs.chromium.org/chromium/src/content/renderer/pepper/ppb_flash_message_loop_impl.cc?q=InternalRun&sq=package:chromium&l=76) which puts off all page load requests while it is in that loop because setDeferred is true.

This was introduced in  issue 569496  and  issue 616907  causes the new window to fail if deferrsLoading is set.

This seems to be a pre-existing problem with this code and my change merely uncovered a problem in this code by changing the mouse move event slightly.

What I see is that without the mouse move change the event loop exits and then calls the actions. But in the case with the high rate mouse moves the event loop remains and asks for a page navigation that fails because it is in the nested event loop.

yzshen@ I'm really not familiar with this nested event loop but it appears it is ultimately caused by your original change.

my investigation from flash side shows that flash player sends the navigate request to PPAPI: PPB_Flash_13_0 Navigate(), then nothing happened.

Sometimes the request can pass through in my tests.

(I haven't worked on this for a long time so I don't think I remember much.)

xzhang@: does the flash side try to close the context menu and exit the nested message loop, before it sends a navigate request?

yzshen@: flash player will not exit nested message loop before the action invoked from the menu item returns, but as soon as PPB_Flash_13_0 Navigate returns, it will be destroyed soon, since Flash Player believes the actions is done.

Thanks, xzhang@!

Is my understanding correct: PPB_Flash_13_0 Navigate is called and it returns; and then the Flash code request to exit the nested message loop (by destroying the PPB_Flash_MessageLoop resource or calling Quit on it); the nested message loop is successfully exited. But the navigate request doesn't seem to be handled at the chrome side.

Thanks!

yzshen@ Yes, that's correct.

M54 is already in Stable now, may be we could take the fix for M55.Lopping to folks who are involved.

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

Confirmed with Anthony (laforge@), this is not an M55 Stable blocker. 

Thanks, govind@ and laforge@!

FYI, I am currently looking into it. And I agree that it is not a stable blocker.

Status update:

I tried canary build and ToT chromium build on Windows. Usually I got 1 failure out of a dozen / dozens of trials.

Lower the priority level given that it is a flash context menu item that is not frequently used, and it only fails occasionally. 

I added logging statements and found that the nested message loop always quits successfully, even when we fail to navigate to the about flash page.

Maybe the problem is in the code of handling deferred navigation? I will keep looking.

@ yzshen: Gentle ping, any update on this.!

The order of the two ipc messages (the one to exit message loop and the one to request a navigation) seems to be indeterministic. When the request of navigation arrives before the message loop exits, it will be dropped.

I will find some time to address it.