Per bug filer, keyboard input is still routed correctly to web content, only mouse is ignored.

I use chrome all the time without closing it and never saw this issue myself on Mac.
Do you run Chrome with any particular flag or something? Do you happen to have any other software that might interfere with OS sending mouse events to Chrome?
I assume when you see the issue the mouse does not work at all on the page. I mean basically you cannot interact with any page using mouse. Right? Does it also happen if you open a new tab at this state?

The original filer notes that the problem continues in both new tabs and new windows.

Given the symptoms described, perhaps there's some problem where the brokering of an input queue down to the renderer fails?

>Do you run Chrome with any particular flag or something?

No. Just run it from the dock.

>Do you happen to have any other software that might interfere with OS sending mouse events to Chrome?

Not to my knowledge. The problem survives a reboot. That is, even if I reboot the Mac, it continues to happen. It most commonly starts happening while I am on twitter.com.

>I mean basically you cannot interact with any page using mouse. Right?

Correct.

>Does it also happen if you open a new tab at this state?

As stated in the bug report, it continues in new tabs and windows.

Do you have any extensions installed?
Are you able to provide us with a trace (input latency)?
Does keyboard event (tabbing, etc) still work?

OK this issue is a bit different than I thought it was. It turns out that what is happening is every single tab process is pegging the CPU, thus is unresponsive. The process that manages the tabs does not appear to get in this state, so that's probably why tab switching is responsive. If I am very patient, eventually Chrome will tell me the tab is unresponsive and let me Kill it or Wait. "Wait" just causes it to appear again eventually, and "Kill" never actually kills. Everything is in limbo at that point.

I have a few extensions installed, but all are fairly popular. I'll leave them enabled for now so I can try and get more useful information out of this.

Unfortunately my attempt at getting a snapshot of the process failed. I'll try again the next time it happens.

Deleted: Screen Shot 2016-09-09 at 4.30.35 PM.png 81.6 KB

	Screen Shot 2016-09-09 at 4.30.35 PM.png 81.6 KB View Download

The keyboard events were still making it to the tab, but I'm just wondering if the keyboard working was just a red herring. 

Thank you for providing more feedback. Adding requester "nzolghadr@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

creis@, nick@ any ideas on how to understand what is pegging these render processes?

How do we get a minidump from a given process that is spun away?

Next time this happens, capturing a trace would be helpful (though probably a bit hard with just the keyboard): https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

The fact that the keyboard works tells me that the compositor thread may be going off the rails. Keyboard should go directly to the Blink thread while mouse passes through the compositor. Note, there was a similar issue reported in issue 639152.

kj@ we don't have anything actionable on this. We really need some traces of what is going on.

Unfortunately, we can't do much with this report. If you can capture a trace feel free to post here and we can reopen the bug.