Issue metadata
Sign in to add a comment
|
Chrome unresponsive to touchscreen use |
||||||||||||||||||||||
Issue descriptionChrome Version: 71.0.3564.0 OS: Linux Chrome is completely unresponsive to touchscreen use on Linux. This regressed in the last day or so. I'll try to bisect.
,
Sep 27
Thanks for reporting, any tips for simulating touch on Linux desktop?
,
Sep 28
Hmm, I can't repro on ToT@#594758 simulating touch with --touch-devices=11 with "xinput --list" printing: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech USB-PS/2 Optical Mouse id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)]... The simulated touch input seems to work okay. I'm guessing you're using a linux laptop with touch?
,
Sep 28
Hmm, the one thing I can't seem to do is drag the window around via the frame, is that what you're experiencing? Simulated touch events work on web content and the views ui in the tabstrip, toolbar, omnibox, etc.
,
Sep 28
No, I seem to get the same behavior even after reverting my CL. I'm not sure if I can repro this breakage, more repro info/tips are appreciated.
,
Sep 28
I'm using a physical touchscreen (id 8 below). Touch is not working for any part of chrome (neither web content nor ui).
$ xinput --list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Laser Mouse id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Cooler Master Technology Inc. MASTERKEYS PRO S with intelligent RGB id=9 [slave keyboard (3)]
↳ Cooler Master Technology Inc. MASTERKEYS PRO S with intelligent RGB id=10 [slave keyboard (3)]
↳ BRLTTY 5.5 Linux Screen Driver Keyboard id=12 [slave keyboard (3)]
↳ HP WMI hotkeys id=13 [slave keyboard (3)]
∼ Weida Hi-Tech CoolTouchR System id=8 [floating slave]
I'll try digging into this on my machine.
,
Sep 28
The issue is in ui/aura/window_targeter.cc: https://chromium.googlesource.com/chromium/src/+/d859d8917a8f25c2b1df516bc67590e37bc2750f%5E%21/#F11 Previously, |screen_location| was the actual screen location. Now it's the root window location. So it's not found to be in the bounds of the display and |root_window| is returned instead of null.
,
Sep 28
Thank you for investigating! I guess the event's target does not match the root_window nor one of its descendants. I'll revert that file's changes, sorry for the regression.
,
Sep 28
Thanks. Also note that |event.target()| is null.
,
Sep 28
Also, I'm able to reproduce this with a mouse simulating touch with --touch-devices, but it depends on the placement of the window. If chrome is on my primary monitor, then it still works (since it's a coincidence that the root location is in the display bounds), but if chrome is on my secondary monitor, then the issue occurs.
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cc86c54fc6f47b7ae43021e8aad610a0d6154948 commit cc86c54fc6f47b7ae43021e8aad610a0d6154948 Author: Mike Wasserman <msw@chromium.org> Date: Fri Sep 28 20:47:56 2018 Revert incorrect WindowTargeter screen location cleanup This CL reverts my recent cleanup changes here: https://crrev.com/c/1246826/7/ui/aura/window_targeter.cc#b140 The event target may not be |root_window| nor one of its descendants. Bug: 890062 Test: Touch input on linux desktop works correctly. Change-Id: Icf49255b55797488ecc186597de910ecde600efc Reviewed-on: https://chromium-review.googlesource.com/1251467 Commit-Queue: Michael Wasserman <msw@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#595206} [modify] https://crrev.com/cc86c54fc6f47b7ae43021e8aad610a0d6154948/ui/aura/window_targeter.cc
,
Sep 28
Should be fixed with the change above, please help confirm, thanks!
,
Sep 28
Touchscreen events are working again after updating past that CL. Thanks. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by mcnee@chromium.org
, Sep 27Status: Assigned (was: Untriaged)