hi Team..this is (tentatively) a P2 affecting one of Enterprise customers.

When should we expect this issue is triaged and schedule for investigation on  the Engineering side? (P2 target Resolution goal towards our Google Cloud customers is 1 quarter), triaging happening weekly with a targeted resolution date.

Could you please help me out?

Many thanks,

Our Enterprise customer is requesting an update on the status of this bug.
Would you mind following this up please? 

Thank you in advance.   

nzolghadr@, assigning this to you since you've been working on this component, feel free to re-assign. Could you please investigate?

Many thanks.

nzolghadr@
Is there any update that can be shared with the customer?

bokan@ you were working on another double tap issue on ChromeOS. Is this one related to that?

Reporter, has this ever worked? I'll ask our QA team to do a bisect.

I'm working on bug 865090 which is related to zoom and double-tap so unrelated.

This also doesn't work on Linux. I suspect it's a drive issue - they're listening for the dblclick event which I don't think we synthesize for TouchEvents, do we?

I believe we do send that. There is a tap count
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/input/gesture_manager.cc?sq=package:chromium&dr=CSs&g=0&l=227

that we use to set the click count of click event and later in the pipeline when sending a click event with detail=2 we also send a dblclick. I will test this on ChromeOS on Monday as well.

CC'ing Mustaq, in case he remembers something.

I tested double tapping using https://rbyers.github.io/eventTest.html:
- Android shows dblclick.
- CrOS doesn't.
- Neither does Linux (tested with touch emulation).

I suspect Blink side is ready to accept clickCount==2, but the gesture event on CrOS doesn't have the info.  Anything to do with OS-level double-tap?

CrOS double-tap was very recently added (and only for tablet mode I think). I'm currently debugging issues where we make Android-only assumptions for touch-action filtering. I'm guessing we only count the taps on Android - could someone on input take a look? I'll let you know if I come across anything suspect in my other bug.

hi team, any news on this issue? 
We have an enterprise customer waiting for update.

thanks

bokan@, Omri and I were testing this on M-70, double tapping an item (normal, not a quick access item) in drive/ while in tablet mode, zooms the page rather than opening the item. We checked and found that they define:

<meta name="viewport" content="width=1000, user-scalable=no">

Does `user-scalable=no` mean double tap to zoom should be disabled? If so, do you think your fix in https://chromium-review.googlesource.com/c/chromium/src/+/1213881 also fixes this issue?

No, the viewport meta tag will have no effect in tablet mode because the viewport setting is turned off.

If the page doesn't define a touch-action or preventDefault touches then zoom in is expected on a double tap.

Sounds like the issue here is that we don't send a dblclick event - Navid, could you have someone in eventing look into it?

Mustaq: Do you know if preventDefaulting the dblclick on Android prevents zoom?

bokan@: Not sure, the repro below doesn't even zoom on double tap on Android.  Any clue why?

https://codepen.io/mustaqahmed/full/rZrdbq

(Also strangely pinch zoom on Android is not suppressed by touch-action:none!)

> bokan@: Not sure, the repro below doesn't even zoom on double tap on Android.  Any clue why?

It has a viewport meta with width=device-width, that disables the double-tap delay (and also double-tap zoom).

> (Also strangely pinch zoom on Android is not suppressed by touch-action:none!)

You probably have force enable zoom turned on in accessibility settings? If not that's a pretty bad bug but I think we'd have heard about it by now.


omrilio@/afakhry@: That reminds me. We spent lots of time a few years ago trying to remove the double-tap delay. This delay (~300ms) occurs after every tap - we don't activate or issue the tap gesture until this tap expires to ensure that it's not part of a double tap. Unfortunately, this means that every tap has 300ms of latency which is poor UX in the general case (e.g. clicking links).

We eventually removed it on all "mobile" pages (i.e. those with the above viewport). There's no such analog on desktop though. Have you thought about how double-tap will affect tapping in tablet-mode?

I'm not sure if the delay is currently active on ChromeOS - it's possible there's other Android assumptions meaning it doesn't activate on ChromeOS. One thing you could do is allow double tap but not use a delay. The effect would be that double tapping on a link would activate the link (and likely zoom in as well).

Mustaq, could you take a look at this?

I have started looking into this now.

The bug reproduces on my Chrome PixelBook on 68.0.3440.118 but at least three times, I was able to open with double-taps when intermixed with mouse clicks:
- mouse click to select then double-tap worked once,
- mouse double-click to open, then close the file, then double-tap worked twice.

Also I can see dblclick events from double-taps on this CrOS device (https://rbyers.github.io/eventTest.html).

Confirmed the intermittent behavior, even w/o any mouse interaction: just keep double tapping on the item name.  After a random number of attempts, the file is opened.

The double-tap doesn't need to be consecutive, repros even when apart by ~a sec.  Once reproed on my first double-tap after page reload.

Another thing: the file opens relatively easily with "sloppy taps"---by sloppy I mean taps that drags the finger a bit.  Try tapping at an angle instead of perpendicularly.

And "dblclick" event is actually fired every time the double tap works.

I was hoping that the odd behavior in #c20 may have gone with a recent fix (crrev.com/c/1213881), but 71.0.3552.6 still shows the bug.

Looking into traces, I found that when tapping doesn't work, RenderWidgetInputHandler::OnHandleInputEvent receives "GestureTapCancel" events, but with working "sloppy tapping" as per #c20, "GestureTapCancel" is not there.  This looks counter-intuitive because sloppy one could cause scrolling and fire tap-cancel.

Here are the event sequences:
[When double tap doesn't work]
  [tap#1] touchstart, gesturetapdown, touchend, gesturetapcancel,
  [tap#2[ touchstart, gesturetapdown, touchend, gesturetapcancel

- [When "sloopy" double tap works]
  [tap#1] touchstart, gesturetapdown, touchend, gestureshowpress, gesturetap, 
  [tap#2] touchstart, gesturetapdown, touchend, gestureshowpress, gesturetap

We just confirmed that it's a problem with the desktop version of drive.google.com, also shown on Android (with desktop page).

We are suspecting that the page's touch handlers are not returning within 200ms, so the touch-ack timeout kicks in, canceling the event stream, hence producing no gesture-taps:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/touch_timeout_handler.cc?rcl=f7bfcc51a05d3ebf17ae4dbc0b5c26c74d280aa4&l=97
The timeout is 200ms on desktop, which is much less than 1sec on mobile.

With "sloppy" taps, the page might be doing something different, so everything works.

I'm not sure about that...here's a trace I grabbed on Linux where I tried double-tapping a few times and none of them worked.

The page is doing very minimal JS - the longest v8.CallFunction in my first double tap is ~5ms. In general, both the main thread and browser look well behaved so I don't think it's an issue of touch ack timeouts.

Deleted: trace_drive_double_clk.json.gz 3.8 MB

trace_drive_double_clk.json.gz 3.8 MB Download

You are right, and my trace on #c24 also reflects the same thing: at most 5ms per touch handlers.

With both scrolling and slow handlers ruled out, how is the page inducing the gesturetapcancels events in #c23?

FYI: In tablet mode, double tap zooms in on any Chrome tab except the NTP.

Tested on web Gmail, Hangouts , youtube, forums, wired.com, cnn.com.

Re #29: Yes, double tap to zoom is not enabled for NTPs nor for internal pages such as chrome://settings, chrome://version, ... etc.

This is a P1 for Tablet.  Do we have an ETA for this landing?

As we observed in #c22~#c27, this doesn't look like an issue with Chrome.  In desktop mode, it seems the page messes up touch event handling in some way.  I am trying to find out what's the exact cause.

This is an issue with drive.google.com event handling as stated in #c23 above.  I now have an explanation for the event sequence mentioned there: preventDefaulting a "touchend" event produces the event sequence for the "doesn't work" case.

djmm@: this is a "Won't fix" case for Chrome, please check with the Drive team.  I will be happy to provide more details of them if needed.  Please let me know if b/115589233 if the right place for it.  After that, I will close this bug.

 Issue 890132  has been merged into this issue.

FYI for weifangsun@: we still need to contact the Drive team.

That looks like the same issue.  Please confirm and close this out.

weifangsun@ and I discussed offline.  Waiting to hear back from Drive team on ownership/plans.

As my bug is dup'ed with this, here is what I observed.


I can double tap to open a file either in the list, or in "Quick Accesses" if it is NOT under "My Drive".

FYI - b/117247235 filed by the Drive Web team.

Closing this in favor of the new b/117247235 filed by the Drive Web team.

I was able to repro the bug on a simpler demo we got from an internal bug (b/117292800 #9).  Here is a public version of the repro:
  https://codepen.io/mustaqahmed/pen/EdWjPJ

It repros only when the CrOS device is in tablet mode.

I studies both the working and non-working cases in depth, found that the renderer is handling a weird gesture event sequence whenever double-tap doesn't work: a gesturetapcancel followed by a gesturetap.  This looks like the core problem.

Here is the detailed analysis:
(The event sequences are as seen at RenderWidgetInputHandler::OnHandleInputEvent.  I tested touch-action=panxy too, same as touch-action=none.)

Laptop mode: *always fires dblclick event*.
  With touch-action={auto, none}:
    [tap#1] touchstart, gesturetapdown, touchend, gestureshowpress, gesturetap,
    [tap#2] touchstart, gesturetapdown, touchend, gestureshowpress, gesturetap.

Tablet mode: doesn't fire dblclick event.
  With touch-action=auto *zooms the page*:
    [tap#1] gesturetapdown, gesturetapunconfirmed, gesturetapcancel,
    [tap#2] gesturetapdown, gesturetapcancel, gesturedoubletap.
  With touch-action=none (nothing happens):
    [tap#1] touchstart, gesturetapdown, touchend, gesturetap,
    [tap#2] touchstart, gesturetapdown, touchend, gesturetapcancel, gesturetap

Note that in tablet mode with touch-action=auto, no touch events are handled.  This seems like the result of our event dispatch optimization when there is no TE handlers.

Attached are traces for 4 cases for comparison:
  mode={laptop,tablet} x touch-action={auto, none}.
The traces are generated through the demo in #c45 above on a PixelBook with Chrome 71.0.3567.0.

Deleted: trace_laptop-mode-touch-action-auto.json.gz 679 KB

trace_laptop-mode-touch-action-auto.json.gz 679 KB Download

Deleted: trace_laptop-mode-touch-action-none.json.gz 662 KB

trace_laptop-mode-touch-action-none.json.gz 662 KB Download

Deleted: trace_tablet-mode-touch-action-auto.json.gz 1.0 MB

trace_tablet-mode-touch-action-auto.json.gz 1.0 MB Download

Deleted: trace_tablet-mode-touch-action-none.json.gz 441 KB

trace_tablet-mode-touch-action-none.json.gz 441 KB Download

As we discussed offline https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/touch_action_filter.cc?type=cs&q=touch_action_filter&sq=package:chromium&g=0&l=144 is where we are converting Tap Unconfirmed to Tap when double tap is not allowed.

The following code switches a gesturedoubletap into a gesturetap:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/touch_action_filter.cc?rcl=84a4df1c6bee3a5312e57877368b5828181bef8d&l=138

In the failing case, this is done after a gesturetapcancel which is clearly wrong.  In trace_tablet-mode-touch-action-none.json.gz above, this happens at 4225ms in the browser process.

M71 Branch is happening in less than 24 hours.

We are on-track from Chrome's perspective: a patch (crrev.com/c/1276846) to fix the missing dblclick event problem in Chrome is ready to land.  I confirmed that it fixes the repro in #c45.

Drive desktop version also needs a fix, see b/117292800.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/70a68cf80ee8095e4a072a3d76e5324869dd9328

commit 70a68cf80ee8095e4a072a3d76e5324869dd9328
Author: Mustaq Ahmed <mustaq@google.com>
Date: Thu Oct 11 20:58:20 2018

Preserve tap-count when a gesture double-tap becomes a gesture-tap.

When a double-tap is dropped through a touch-action (e.g.  "none" or
"manipulation"), we replace the double-tap event with a single-tap which
is the second single-tap in the gesture sequence.  Blink dispatches
compat "click" events for both these taps.  Without a correct tap-count
(==2) in the second tap, a follow-up "dblclick" event is not dispatched,
which is wrong.  This CL fixes the problem.

Bug:  874474 
Change-Id: I25f9806e5ec9f211f9f83d59e8949052a816aaf3
Reviewed-on: https://chromium-review.googlesource.com/c/1276846
Reviewed-by: Xida Chen <xidachen@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#598928}
[modify] https://crrev.com/70a68cf80ee8095e4a072a3d76e5324869dd9328/content/browser/renderer_host/input/touch_action_filter.cc
[modify] https://crrev.com/70a68cf80ee8095e4a072a3d76e5324869dd9328/content/browser/renderer_host/input/touch_action_filter_unittest.cc

[Auto-generated comment by a script] We noticed that this issue is targeted for M-71; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-71 label, otherwise remove Merge-TBD label. Thanks.

No merge required: M71_branch_point=599034 is after the commit.

 Issue 898937  has been merged into this issue.

Tested on a Scarlet/Dru, Platform 11151.11.0 dev-channel and issue still exists. Pls lmk if i'm not doing it right :)

It is consistent now, but with the latest Chrome Dev, I can't open any file in the touch only mode. Unlike I commented in #41.

In the touch only mode, double tap does zoom in and zoom out. e.g. on the PixelBook, if the keyboard is available, touch to double tap, it opens a file. If I flip the device to be touch only mode, touch to double tap will change the zoom.

Curious why this is tagged as a beta blocker for such an old issue.  It's not a M71 regression, correct? If so can you identify the comment calling it out?

It's not a M71 regression, it got exposed in M71 through a Drive bug.

bayo@: Could you please confirm if the repro in #c45 works for you?  Double-tapping on "pan-x pan-y" should show an alert.  I see it WAI on my PixelBook (M71).

Device : Scarlet Dru

Auto : zoomed in/out
pan-x pan-y : dialog box says 'dblclick'
none : dialog box says 'dblclick'

Video -- https://drive.google.com/file/d/1-17hVRGoiT-oWKVAh7Aqrje9ZUgpGdyj/view?usp=sharing

Google Chrome 71.0.3578.21 (Official Build) dev (32-bit)
Platform 11151.11.0 (Official Build) dev-channel scarlet-unibuild (dru)
Firmware Version   Google_Scarlet.10388.59.0
JavaScript V8 7.1.302.6

This looks WAI for Chrome.

Drive works when both the Chrome fix (#c52) AND the drive fix (internal bug b/117292800) are in.  The internal bug verified the fix.

bayo@, klobag@: could you please make sure you have both?

According to the internal bug, the drive fix is not pushed out yet to most of us. That explains what I saw last weekend.

Re-closing this based on the internal bug.  Please reopen if chrome shows the issue even with the updated Drive frontend.

Confirm it is fixed for me now. Thanks.