The hit test action in Chrome's accessibility code has evolved over time and could be refactored to be more efficient and more flexible.

For historical reasons, right now hit test is an action that can be triggered from anywhere. The result of a hit test is that it fires an event, typically a HOVER event, but it can be anything.

This matches the original use case, which is to support touch exploration on Android and Chrome OS.

There are other use cases for hit test - increasingly it's also used as more of an asynchronous API that wants a response to a specific hit test. The current architecture has the problem that if multiple sources are all doing hit tests, you can't distinguish between the resulting events. Rewriting it as more of an IPC with a response would allow us to solve both use cases.

Finally, hit testing of iframes works correctly but could be more efficient. Right now we start with the main frame, go to the render process for a hit test, then if that hits a frame (or webview, etc) we ping back to the browser process and pong to the next render frame, even if it was the same process. So we could make this more efficient by using RenderWidgetHostInputEventRouter to pick the right RWHI to send the message on, then from the RWHI hit test the correct frame within one render process. That'd be a fair amount of refactoring, though.

Test coverage is decent but if we did that refactoring we'd have to add additional test coverage for OOPIF.