Context:
I'm trying to land a change that causes RenderWidgetTargeter to always use the root view's InputTargetClient when starting an async hit test, and then recurse downward as it hits OOPIFs. This is correct because sometimes synchronous hit testing will identify an OOPIF as the target, but actually its parent should receive the event.

Problem:
InputTargetClient doesn't know about BrowserPlugin. An async hit test over a BrowserPlugin will always tell the router to send to the top-most view.

This isn't a problem for most events, since BrowserPlugin forwards most event types anyway from the parent renderer to the child renderer. However, touch events in particular have been converted to rely on surface-based hit testing to solve some other bugs and there is a DCHECK that prevents them from being forwarded. Hence my CL is causing a WebViewTest failure.

Short term solution:
I am planning on avoiding asynchronous hit testing when it his a BrowserPlugin, and relying on the synchronous quad-based hit test result. Please let me know if anyone strongly objects to this.

Long term solution:
Is this important enough to fix more correctly? BrowserPlugin should be gone within the next few months. I believe it only hosts PDFs at this point, which isn't a trivial use case. It seems like the short term solution doesn't cause any regressions that haven't already been there for a while.