UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce the problem:
The problem is highly timing dependent and I did not manage to reproduce it in content_shell on chromium master. This is what triggers it in our integration: 

1. Start the integration and load the attached test case
2. Select TC5
3. Repeat steps 1 and 2 until the NOTREACHED DCHECK is hit...

What is the expected behavior?
No DCHECK hit

What went wrong?
When the dropdown closes after selection, sometimes an input event for that window arrives after the renderer view has been unregistered as a route in the input handler (InputMsg_MouseCaptureLost it looks like). This causes the newly added NOTREACHED in InputEventFilter::QueueClosureForMainThreadEventQueue to be hit.

Did this work before? Yes 

Chrome version: 61.0.3142.0  Channel: dev
OS Version: 
Flash Version: 

This is a regression from https://codereview.chromium.org/2765583002.

I would think that simply removing the NOTREACHED in InputEventFilter::QueueClosureForMainThreadEventQueue may be acceptable? Maybe also removing the message push since one may assume there is no longer a receiver when there is no route?
 

Deleted: crash_on_input_in_dropdown.html 355 bytes

crash_on_input_in_dropdown.html 355 bytes View Download