Issue metadata
Sign in to add a comment
|
Touch handler broken in ToT Chrome [Linux] |
||||||||||||||||||||||
Issue description
Version: refs/heads/master@{#435095}
OS: Linux (but I haven't tested on others yet ...)
What steps will reproduce the problem?
(1) open http://rbyers.github.io/paint.html
(2) touch the screen
What is the expected result?
Traces of the finger's path should be drawn.
What happens instead?
Nothing.
*** or ***
(1) open chrome://chrome-signin/?source=0
(2) try clicking links (nothing happens)
What is the expected result?
Navigation to the linked page.
What happens instead?
Nothing.
Please use labels and text to provide additional information.
,
Dec 1 2016
This bug is a blocker for fixing page-scale propagation for OOPIF, which is in itself a blocker for TDI
,
Dec 1 2016
I couldn't repro using touch emulation in devtools. James, did you use a touch-screen or used devtools emulation?
,
Dec 1 2016
Touch emulation at present is rather broken, you'll need a real touchscreen. Perhaps try a ToT build on a Pixel (though I haven't checked myself to see if this repros on CrOS).
,
Dec 1 2016
I just tried this on a Pixel. Could not reproduce.
,
Dec 1 2016
Same for me, couldn't repro in Pixel ToT with all chrome://flags at default values. Wondering if touch-event flag is disabled in James case.
,
Dec 1 2016
I'll double check that later tonight when I'm back in the office. Would touch stuff work on pages without touch-handlers if the flag is not on? I'm testing with a profile that, before I sync'd my repro yesterday, worked ok. So I'm assuming the profile had that on, but I'll verify in any case.
,
Dec 1 2016
Yeah, we landed last week a touch-flag change (crrev.com/2467913002) that missed the web-compat implications for part of the change. We are working on a fix (crrev.com/2531413002) now. Until we land the second CL, set the touch flag to enable or disable (not auto) and see if that works for you.
,
Dec 1 2016
Sure, I'll give that a try tonight, and update the bug.
,
Dec 2 2016
Yeah, that was it. I'm assuming the flag was enabled before, but now it was showing 'disabled' in about:flags. Weird, cause I'm assuming it wasn't disabled before, otherwise the events would have failed prior to my repo sync too.
,
Dec 2 2016
Hmm, if the flag switched from "enabled" to "disabled" automatically, I suspect chrome profile might have messed up the stored flag state even though we didn't modify any exposed string! Anyway, the fix (crrev.com/2531413002/ ) landed last night. You can safely to back to "auto" after it. Let us know if you still see any problem.
,
Dec 2 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Nov 30 2016Owner: mustaq@chromium.org
Status: Assigned (was: Untriaged)