Able to reproduce the issue on Windows 10 and Ubuntu 14.04 with chrome #58.0.3029.81 , #60.0.3081.0 and also in earlier version M45-45.0.2454.93.
This is non-regression issue, hence marking it a untriaged

Attaching a screen-shot for reference.

Note:
Builds less than M45 are crashing in my system.

Deleted: Issue 714573.mp4 362 KB

	Issue 714573.mp4 362 KB View Download

I've got other tap-delay detection bugs to fix so I'll take this one on as well.

Load balancing this onto sahel@

Chao, could you investigate why the tap delay is occuring in iframes? The relevant place to start is in RenderWidgetHostImpl::SubmitCompositorFrame, the bit about IsMobileOptimizedFrame. If that message comes from the renderer, the browser gesture detector will disable the 300ms delay. I would expect that to work for the whole page but since it's on RenderWidgetHost (each I frame has a RenderWidget I believe) perhaps we need to tell all the other widgets about the change.

I upload the test on http://ht.chaopeng.me/iframe-delay/index.html
I can not feel the 300ms delay not obvious like the video.
I have tried devtools and Android.

Yup, I can't repro anymore either. Closing as such.

Hello,

The tap delay is still obvious for me.

You can see it in the attached video:
- the style of the iframe button doesn't change when clicked
- the link in the iframe doesn't change to red when clicked (I am clicking it twice at 10")

Do you still think there is no a bug?

Chrome version: 64.0.3282.119  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)

Deleted: iframe-tap-delay-2018-01-30.mp4 5.2 MB

	iframe-tap-delay-2018-01-30.mp4 5.2 MB View Download

Yes, I found the style in devtools weird. The button edge disappear on Mac.
Maybe we should open a new issue for that.

Yes please,
Originally this weird style behavior was the reason why I opened this issue.

Ok, that's not the 300ms tap delay but it seems we're not reflecting the visual change in active pseudo-class (or maybe we're not applying the :active pseudo-class at all :/).

Keeping this bug is fine, I've updated the title to better reflect the bug. Thanks for the clear repro video!

Thanks for reopening,

But I still think this behavior is linked to the 300ms tab delay:
If you make a long touch (> 300ms?) to an interactive element of the iframe then you can see :active pseudo-class styles applied.

Yeah, I noticed that too. It's possible it's related but it might also just be coincidence. The 300ms delay is applied in the browser process for an entire page so unless the iframe is out of process (it's not in this case) I wouldn't expect there to be a behavior difference here.

I logged the Document::UpdateActiveState. We set the correct element immediately include SetActiveElement and element.SetActive. I have tried add layout after that but it does not work. 

It seems active vision effect is a delay animation. Click on the button, you can see effects are after mouse release. bokan@ do you know where we actually apply the effect?

Nope. Are you sure it's an animation/timer task? I imagine we just need a repaint (rather than a layout) - maybe that's not getting scheduled?

If you can find the object that paints an Anchor or Button Element you could probably print out some stack traces from the Paint method and see how we call into that after the mouse down happens in the main frame/working example.

e.g. I expect an anchor tag would be painted by InlineTextBoxPainter::Paint

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

commit 1760ef3d17bbe5ee47db6e057e54822885cbafd3
Author: chaopeng <chaopeng@chromium.org>
Date: Thu May 03 14:15:49 2018

Store the last_show_press_timestamp_ in root frame EventHandler

This issue is caused by:

1. When user tap on screen, we receive TapDown, ShowPress, Tap.
   TapDown and ShowPress will active the tapped element. Then Tap
   checks the LastShowPressTimeStamp() to stay active or cancel.
2. Each frame has GestureManager and we store LastShowPressTimeStamp()
   in GestureManager.
3. We check the root frame GestureManager LastShowPressTimeStamp()
   before hit test so we read the wrong LastShowPressTimeStamp().

In this patch, we move last_show_press_timestamp_ to root frame
EventHandler so we don't need to hit test and figure which
GestureManager should use.

Bug: 714573
Change-Id: I80c75bf2f0493a6cbfd3b24873e1127da4fd7a27
Test: EventHandlerSimTest_TapActiveInFrame
Test: Manual test for OOPIF
Reviewed-on: https://chromium-review.googlesource.com/1041065
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555719}
[modify] https://crrev.com/1760ef3d17bbe5ee47db6e057e54822885cbafd3/third_party/blink/renderer/core/input/event_handler.cc
[modify] https://crrev.com/1760ef3d17bbe5ee47db6e057e54822885cbafd3/third_party/blink/renderer/core/input/event_handler.h
[modify] https://crrev.com/1760ef3d17bbe5ee47db6e057e54822885cbafd3/third_party/blink/renderer/core/input/event_handler_test.cc
[modify] https://crrev.com/1760ef3d17bbe5ee47db6e057e54822885cbafd3/third_party/blink/renderer/core/input/gesture_manager.cc
[modify] https://crrev.com/1760ef3d17bbe5ee47db6e057e54822885cbafd3/third_party/blink/renderer/core/input/gesture_manager.h