New issue
Advanced search Search tips

Issue 890062 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 28
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Chrome unresponsive to touchscreen use

Project Member Reported by mcnee@chromium.org, Sep 27

Issue description

Chrome 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.
 
Owner: msw@chromium.org
Status: Assigned (was: Untriaged)
Bisected to https://chromium.googlesource.com/chromium/src/+/d859d8917a8f25c2b1df516bc67590e37bc2750f
Thanks for reporting, any tips for simulating touch on Linux desktop?
Labels: Needs-Feedback
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?
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.
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.
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.
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.
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.
Labels: -Needs-Feedback
Thanks.

Also note that |event.target()| is null.
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.
Project Member

Comment 11 by bugdroid1@chromium.org, 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

Status: Fixed (was: Assigned)
Should be fixed with the change above, please help confirm, thanks!
Touchscreen events are working again after updating past that CL. Thanks.

Sign in to add a comment