Note, that for touch hit testing we may need/want to expose some of these attributes (such as radius) anyways to allow retargeting based on the touched area.

kenrb@ Can you comment yes/no from a security viewpoint

I'm curious how this would work from an implementation viewpoint. I presume that for an event where we don't know which renderer it should arrive via the existing dispatch mechanism? 

I think we discussed this at the time of the initial implementation, but decided not to do because of security concerns. I don't remember if the concerns were raised from the security team, or if they were speculative.

The implementation should not be hard: instead of asking for a target at a specified point, the API would take the whole event as the input. The return value from the query would indicate whether the event has already been handled, or whether it needs to be re-targeted+dispatched.

Slow hit testing is all on the main thread. So you are talking about a
browser thread to Main Thread to compositor thread post of pending event... vs
browser thread to main thread to browser thread to compositor thread.

Also all of the browser side filtering logic is done based on knowing the target (not at the hit test time).. So Touch Action Filter, gesture event queue, fling boosting, etc all change state about sending an event to the renderer. To do this possibly seems like a large undertaking.

Slow hit testing is the supposed to be the path not taken frequently on purpose I don't know if shaving off a little bit of time of a long operation for the engineering complexity would be worth it.

Do you have a design doc? 

The idea that we had considered and rejected for security problems was doing BrowserPlugin-style event forwarding, where the event is just passed to the parent frame, hit testing is done in the renderer, and then when appropriate, it is sent back to the browser targeted to the child frame. The problem there is that it would allow a compromised renderer to dispatch arbitrary events to a cross-origin frame which is counter to the goals of Site Isolation.

This proposal wouldn't have that problem. I seem to recall something like this was briefly floated but the complexity sounded a lot higher than slow path as it was implemented. I share Dave's concerns that this might be infeasible for touch and gesture events.

Re comment 5:
> Slow hit testing is the supposed to be the path not taken frequently...

That is the goal, but the slow path is very frequently taken until hit test regions are fully implemented. Currently every mouse or touch event that is over top of an OOPIF uses this path, and Site Isolation is supposed to be default on Stable in Chrome 67.

Re #5, I think in the cases where touch action filter or existing flings were happening we don't need to do targeting as we already know the target. This proposal is about identifying and dispatching to the initial target frame for a touch sequence.

Also, I have not written up a design document for this yet, but this seems like it will be less work to get the same level of performance for top-frame event dispatch than tackling all of the complexities of accurate hit testing.

For example, passing enough data for the browser to do accurate hit testing will require sending complex regions for composited layers which we don't currently build in cc, as well as enabling using clip masks from hit test nodes (issue 842684). This work will likely to take many months to complete.

I suggested a metric in  issue 732417  to track how many hit testing round trips we typically do. i.e. for the cases where this is 1, doing this would put the "slow path" on performance parity with accurate hit test data.

Just to close the loop on this I chatted with Dave and realize now that in order to do this without introducing a lot of code debt we'd have to change the way OOPIFs are implemented to use a single RenderWidgetHostImpl (as this maintains state based on dispatched events) for all the OOPIFs rather than choosing one to target, and do hit testing and dispatch together. This would be a pretty major refactoring.

Also, since we only need to end up in this path when the target frame is unclear the number of cases where this occurs shouldn't be too bad.

I don't think that we should proceed with this if we can avoid it. Dave also had other suggestions such as, since we have to do a main thread hit test anyways, we could have the main thread scheduler wait for the input event that it knows should be coming from the regular event dispatch route. This would ensure that the dispatch would be picked up by a free main thread while not requiring drastic changes to the dispatch logic.