New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 617626 link

Starred by 1 user
Status: WontFix
Owner:
rjkroege@chromium.org
Closed: Aug 14
Cc:
█ ben@chromium.org
tdres...@chromium.org
sky@chromium.org
mustash-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Target-locking for touchpad

Project Member Reported by sadrul@chromium.org, Jun 6 2016 
For touchpad scroll/pinch events, the target that receives the first event should continue to receive the events even if the target moves from under the cursor, until user lifts fingers from the touchpad (see more in issue 526463)

Comment 1 by rjkroege@chromium.org, Oct 4 2016

Components: Internals>MUS
Labels: Proj-Mustash

Comment 2 by rjkroege@chromium.org, Dec 13 2016

Components: -MUS
Labels: -Pri-2 Proj-Mustash-Mus-WS Pri-3
Owner: rjkroege@chromium.org
I've assigned to myself to update appropriately when we have a better sense of our input futures in mus

Comment 3 by lafo...@chromium.org, Feb 26 2018

Components: -Internals>MUS Internals>Services>WindowService

Comment 4 by jamescook@chromium.org, Apr 24 2018

Labels: -Proj-Mustash-Mus-WS
Deprecating label Proj-Mustash-Mus-WS in favor of Components.

Comment 5 by benhenry@chromium.org, Aug 1

Status: Assigned (was: Available)

Comment 6 by jamescook@chromium.org, Aug 14

Labels: -Proj-Mustash Proj-Mash-SingleProcess
Bug scrub: Is this still relevant with WS2?

Comment 7 by sky@chromium.org, Aug 14

Status: WontFix (was: Assigned)
I believe we get this for free as we're using event targetting in ui/events.
►

Sign in to add a comment