mus: Touch (and mouse?) interaction is sometimes not processed |
||||||
Issue descriptionmus: Touch (and mouse?) interaction is sometimes not processed Oshima first noticed this issue, and I've been able to repro. The exact trigger is unclear, so I haven't found reliable repro steps. On Chrome OS 65.0.3292.0 (ToT @ #523106) (1) Run chrome --mus (I've seen this on link, Oshima saw it on cyan) (2) Use lots of touch interaction across desktop/shelf/windows... Expected: touch input is always handled. Actual: touch input sometimes isn't handled. Details below. Sometimes touching the app-list button doesn't show/hide the app-list). Sometimes long-tapping the desktop wallpaper doesn't show a context menu. Sometimes swiping the shelf up/down doesn't show/hide the shelf/app-list. When it happens, several repeated touches don't work, then it fixes itself...
,
Dec 13 2017
,
Dec 16 2017
,
Jan 19 2018
My suspicion is we're dropping an event and the GestureRecognizer is getting confused.
,
Jan 19 2018
Touches don't work on the shelf with the highest display resolution with --mus. It does seem to work at other resolutions; reproed on cyan at 65.0.3319.0
,
Jan 19 2018
This seems to repro very reliably at 1536x864, and the mouse also doesn't work on the shelf.
,
Jan 19 2018
It also affects the system tray menu, --show-taps shows the dot in the right spot
,
Jan 19 2018
Scott, you've probably already discovered this, but it repros on linux-desktop chrome os with just "chrome --mus" + "ctrl-shift-minus" and trying to click the shelf, system tray, or notification bubbles. I can't repro the original flaky event dropping anymore.
,
Jan 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c727f117c7d9f86f81022a9720766d004508ccd4 commit c727f117c7d9f86f81022a9720766d004508ccd4 Author: Scott Violet <sky@chromium.org> Date: Sat Jan 20 00:26:40 2018 Fix event targeting bug The bug occurred in finding the valid target. Specifically if the root has a transform we transform the event first, and then compare against the size of the root. For transforms that result in increasing the location (transform value < 1) the location would end up outside the bounds of the window, which results in treating the location as in the non-client area and targeting the root. The fix for now is not to consider the root as a target for the non-client area. A better fix may be to potentially transform the size by the targets transform (if there is one), but I'm holding off on that for now. We don't do scale bounds in WindowTargeter either. BUG= 794262 TEST=covered by tests Change-Id: If7a913d934808fd4ffc404f74eea73d9f98b71ab Reviewed-on: https://chromium-review.googlesource.com/877219 Reviewed-by: Michael Wasserman <msw@chromium.org> Commit-Queue: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#530683} [modify] https://crrev.com/c727f117c7d9f86f81022a9720766d004508ccd4/services/ui/ws/window_finder.cc [modify] https://crrev.com/c727f117c7d9f86f81022a9720766d004508ccd4/services/ui/ws/window_finder_unittest.cc [modify] https://crrev.com/c727f117c7d9f86f81022a9720766d004508ccd4/services/ui/ws/window_manager_state_unittest.cc
,
Jan 20 2018
,
Feb 26 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ovanieva@chromium.org
, Dec 13 2017Status: Assigned (was: Untriaged)