New issue
Advanced search Search tips

Issue 724521 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Do event targeting while dispatching previous events

Project Member Reported by riajiang@chromium.org, May 19 2017

Issue description

Right now we don't do event targeting if we are actively dispatching a previous event because the result of event targeting might depend on the result of event dispatching, e.g. a mouse press that would create a capture window followed by other mouse presses, following mouse presses should go to the capture window created by the first mouse press so we need to wait after we received the ack for the first event dispatching to start event targeting for subsequent events. But in some other cases we might not want to wait to do event targeting? E.g. if there are two windows right on top of each other and their close buttons align with each other, say window A is on the top and B is at the bottom, now when user click the close​ button of A (event E1), and click again (event E2) while waiting for the targeting+dispatching of E1, both events should target to A instead of closing both A and B. Explore when we should do event targeting while dispatching previous events.
 

Comment 1 by sky@chromium.org, May 19 2017

I'm not understanding what you are proposing. We need to wait for the ack before targeting as processing the event may have side effects.
In some cases, we can more aggressively take advantage of asynchrony than target/dispatch/ack always performed in lock step. For example, consider a stream of mouse moves sampled at 240Hz and the screen redrawing at 60Hz. All four mouse moves will use the same targeting data so can be targeted before the (possibly implicit) ack of updated targeting information arriving.

Comment 3 by sky@chromium.org, May 23 2017

Even mouse moves can have side effects. Say showing a tooltip/bubble.
Components: -Internals>MUS Internals>Services>WindowService
Labels: -Proj-Mustash-Mus Proj-Mustash
Migrating Proj-Mustash-Mus to components Internals>Services>WindowService and Internals>Services>Ash

Status: WontFix (was: Available)
This bug refers to the event dispatching path that has been removed.

Sign in to add a comment