Update:
Rechecked the above issue on Mac(10.12.6,10.13.1,10.13.4) using latest canary (build #67.0.3375.0) and fix is working as intended.
Please refer attached screen cast for the same.

Thank you...

Deleted: Canary_behaviour.mov 7.5 MB

	Canary_behaviour.mov 7.5 MB View Download

Note: Please ignore my previous comment.

I don't have a Windows-10 Touch machine to try this. Was not able to reproduce on my Win10 with "device mode" on from DevTools. Either way, this seems like a bug that is unrelated to the Settings UI, and related to how touch events work (or don't work) in general on Windows-10 Touch.

Unassigning, for now, so that others that have such a machine can pick this up.

I think that the description/analysis of this bug is slightly misleading. I don't ever see the bookmarks button being disabled in the video, but I do see it not responding to taps sometimes. Is there any other indication of it being "disabled", or was that just a way of describing that it was not responding.

Does it ever not respond if you tap more slowly, perhaps once every couple of seconds?

I suspect that the issue is related to double-click versus single-click messages. When the user clicks the mouse once them a WM_LBUTTONDOWN message is sent, and a second click will be either the same message or WM_LBUTTONDBLCLK. For touch events the messages are ISG_TAP and ISG_DOUBLETAP. So, perhaps we changed something in our handling of ISG_DOUBLETAP messages. We don't handle them directly so it would have to be some difference in how Windows translates them to regular mouse messages.

Does the bug happen when toggling the home button, or just with the bookmarks bar button?

I cannot reproduce the button with chrome Canary on my surface laptop, using touch taps.

Not sure if this is related, but mentioning it just in case. The UI code is utilizing the approach described at [1] to eliminate the 300ms delay that the browser used to wait to determine whether a double-tap would occur.

Specifically the way this is prevented is at [2], with the CSS "touch-action: manipulation;" rule. Could it be that this CSS rule is not working as expected on Windows10 Touch? 


[1] https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away
[2] https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/settings.html?l=14

> Could it be that this CSS rule is not working as expected on
> Windows10 Touch? 

Could be. A couple of things could help to better understand this bug:

1) What type of machine is this happening on? I can't reproduce it on my touch-screen SurfaceBook
2) Have any changes to the Windows input settings been made, such as changing the double-click timings?
3) Does the bug happen when toggling the home button, or just with the bookmarks bar button?

Answering the first two might help us reproduce the bug. Answering the second one might let us isolate possible causes, by hinting as to whether the bug happens with all buttons or just one.

FYI, a similar issue is reported at issue 820888, which makes me think that there is something wrong with how touch events are implemented at a lower layer for Windows10 Touch setup.