Assigning to asimjour@chromium.org, based on ownership of the blocking bug.

Assigning to acondor.
@acondor, this should be fixed after you land your WIP on input.

I was able to reproduce this also in desktop, when clicking very fast. However, I couldn't reproduce in 2D android. The event callback for the click still runs every time.

I just talked with nzolghadr@ and this is expected when the click up happens faster than the refresh rate. This is not reproducible in android 2D because it's very difficult to touch that fast as opposed to clicking.

A stupid question: We do have some mechanism in EventHandler to ensure the active state is shown for gesture type events. (I assume vr is now using stylus type event instead of mouse type)
Navid, do you know why this is not working correctly?

See: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/input/event_handler.cc?dr=C&sq=package:chromium&g=0&l=1700

I don't think we have that delay for the mouse path.
I asked Aldo about whether they get the hover effect when moving the pointer around and it seems that they do. As I believe we don't have hover effects for the touch event movements then they must be using the mouse event path I believe (regardless of the type of the pointer type). Aldo can you confirm?

My understanding is the logic is similar to what we have on direct manipulation: when hover, send mouse events; when button down, send touch events. So they can support both scroll and hover. 
Looking into the code I'm not sure whether vr is using the same gesture provider :) 

VR injects MotionEvents, but we use TOOL_TYPE_STYLUS for both hover and touch events. What you are saying is that if we use FINGER, then the event handler should add the delay?

It is less about what type you set but rather which path you inject the input. So for example in here the ui::MotionEventAndroid either comes in OnTouchEvent or OnMouseEvent:

https://cs.chromium.org/chromium/src/conten render_widget_host_view_android t/browser/renderer_host/.cc

and both of them handle MotionEventAndroid. Although the logic on how you inject the input might rely on the type of the MotionEvent you have. My guess was that since you are getting the hover effect for when you move the pointer around it had to come from the mouse path. But what Ella says is also definitely a possibility.

If you can give me a few pointers on where your code lives and where you inject the input we might be able to follow the code path to figure what the logic is and how the events are being routed.

A easier way to figure out: do you show context menu when long press?

BTW I don't think you'd want to use FINGER, stylus is better for your case ;p

cc mustaq@ as he might remember what happens ot stylus here.

The code that decides when to send the mouse events vs touch events is here:

https://cs.chromium.org/chromium/src/ui/android/java/src/org/chromium/ui/base/EventForwarder.java?type=cs&q=TODO%5C(mustaq%5C):+file:%5C.java&g=0&l=65


It does seem that we are missing TOOL_TYPE_STYLUS in the check. Which makes me wonder how you are getting the hovering effect. From this issue 592082 it does seem that we are sending TOOL_TYPE_STYLUS in contact from touch and from mouse path when it is not in contact (as Ella said). But I don't see that logic in the code above. mustaq@ added that part of the code back then. Mustaq, Do you remember where we get that logic?

I checked with Mustaq last week. As he remember, we only treats type mouse as mouse.

And also, the looks like vr handle hover and non-hover event is different. The code here: https://cs.chromium.org/chromium/src/chrome/browser/vr/platform_ui_input_delegate.cc?q=chrome/browser/vr/platform_ui_input_delegate.h&sq=package:chromium&dr=C&l=54

I think we don't need to worry about this issue since  issue 733656  is resolved.

The code in the platform_input_delegate is being refactored to remove the confusion with the used blink structures. Please refer to https://cs.chromium.org/chromium/src/chrome/browser/android/vr/android_ui_gesture_target.cc to see the actual injected events.  issue 733656  ended up being unrelated.