Earlier this month, I noted that Chromebooks in tablet mode were exhibiting touch issues. Since then, I’ve been monitoring any bugs filed for this problem and it just paid off: There’s a workaround fix I’ve tested that’s simple to apply.
By default, this experimental flag is on: According to the description, it adds some logic for “hit testing”, likely to predict likely touch points or to assist in accuracy. Of course, in tablet mode, it’s not currently assisting in accuracy as it currently works, at least not when rotating a display.
To disable this flag, type chrome://flags/#enable-viz-hit-test-draw-quad in your browser bar and set the status to “Disabled”. You’ll need to restart the browser for the change to take effect.
I followed this process on two different Chrome OS devices and can confirm that it solved the problem for the links I clicked. While I can’t test every possible web page or scenario, that’s a good sign.
For now, this is a workaround fix. The Chromium OS team notes that “This bug is marked as a 68 stable release blocker, and we are coming up on stable in a couple weeks, so we need to get it fixed or reclassify it.” That suggests the team is looking into a long-term fix so that the flag will work when set back to its default state; hopefully in time for the Stable Channel of Chrome OS version 68.
5 Comments
Does this fix impact lack of touch detection for Android Applications?
Not sure as I haven’t tested; that issue may present itself in specific Android apps. Have you filed a bug for it, out of curiosity?
I filed one early, but not with the final narrowing of symptoms before I went back to stable.
I probably should shift back to dev just so I can see if this works or not, and file a fully diagnosed bug if it doesn’t.
I wish they would mark specific applications as being “dev channel clean” so you didn’t have to re-dowload *everything* (especially the Android apps) each time you flipped channels.
I tried the workaround. It improves crostini improvement for most of the linux apps I have tried, but did not seem to solve anything for Android apps.
The performance gap that had my Speedometer 2.0 measuring in the low teens also seems to be gone, I’m measuring in the low 20s as expected.
I haven’t found a specific pattern no what works and doesn’t work yet. For example, abiword is unusable while libreoffice works flawlessly. Dia also works fine, as do native Chrome apps and the Chrome browser.
So for now I’m staying on the dev channel.
Thanks!!!! It cleared my issue.