I think dropping the event makes sense in this case? Sending the event to another target is kind of strange and it violates the goal of targeting what the user actually sees? Right?

Yes I don't think it makes sense to send events to that invalid target, but waiting for the next begin frame would actually allow us the find the correct target with the updated hit-test data?

Consider if the event is a mouse down. If you drop the event then all the subsequent drags are in a weird state. I tend to think we should reprocess the event.

What about just giving the event to the window tree parent of the now-invalid window?

On second thought that might not be great. If the parent has two child windows stacked on top of each other, and the top one goes invisible, then the parent shouldn't get it. From the user's perspective it is random as to whether the disappearing window or the still-visible sibling gets the event but the parent getting it wouldn't make sense.

You also need to be able to handle the case where a mousedown or touchstart has actually been delivered to the old window and it disappears immediately afterward -- subsequent mousemoves, mouseups, and touch events will also need to be dealt with, and they should not be retargeted to a different window. Dropping a mousedown to a invisible window is probably reasonable if you make the behavior match that case.

Crazy idea: UI operations should be tagged with frame tokens so they don't take effect until the corresponding CompositorFrame is received and activated in Viz. WDYT?

The way hit-testing currently works, in blink and in aura, is whatever the state of the world is, internally, in blink and in aura. It does not necessarily reflect what is on screen. So falling back to that model, i.e. ask the parent window/client to do the targeting would not be too bad. The problem is, it adds to the latency. But so does waiting for the next update from viz (i.e. comment #2). So the choice is between doing a slow hit-testing, vs. discarding the event-sequence altogether. This would be similar to starting a sequence on a window, and the window gets destroyed before the sequence ends (comment #5). So it's probably going to be simplest to discard the event sequence altogether (what kenrb@ proposes in comment #5).


> Crazy idea: UI operations should be tagged with frame tokens so they don't
> take effect until the corresponding CompositorFrame is received and
> activated in Viz. WDYT?

Does not sound related to targeting? (closing a window can happen because the child died, for example) ... but also, sounds like it would only add to the latency. Anyway, maybe this should be a separate bug.

I'm curious: why is dropping mousedown a problem so long as the mouse up is then also discarded? Is there a place in the UI where mouse moves alone are harmful?

My concern is we don't attempt to retarget on a drag. A quick look shows we don't, so ignoring the whole sequence seems reasonable.

Re #8: There probably isn't a reason to discard mouse move events. Move events should be captured by the window that received a mouse down, but if that window goes away, it seems fine to stop capturing them.

Cleaning up old Proj-Mustash labels.