Does this only happen while in VR?

Yes, only in VR

Biao, can you please take a look?

bisected to this one: https://chromium-review.googlesource.com/c/chromium/src/+/615424

+dtapuska
In VR, we generate WebMouseEvent in a GL thread and then dispatch these events to content area through RenderWidgetHost.
And once user click the fullscreen video button, the events that we deliver to content are:
kMouseDown
kMouseUp
kMouseMove
...
kMouseLeave (if cursor leaves the fullscreen region)

Do you see anything that could be wrong?

Do you have rAF aligned mouse events on? I wonder if the mousemove isn't actually getting to the DOM because of a lack of BeginMainFrame signal?

Try disabling raf aligned mouse events maybe?

I am not quite sure if fullscreen video controls use rAF aligned mouse events. David@ do you happen to know?

From what I can tell is that the fullscreen video control will hide itself if mouse didn't hover on it or mouse didn't move for a while while not hover on the control. Given that the control always show after entering fullscreen now. It seems like the hover state never cleared after fullscreen started. I could still click the control to pause/resume videos. But the control still stays there after I interact with it.

Thanks Dave for all the help.

The problem is we are entering into this loop:
1. Mouse event dispatched after a page relayout from here (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/LocalFrameView.cpp?rcl=9ee94f7ebc8efb880a1dc29e4494576a8f0a49f0&l=2587). The relayout is due to the progress bar update in video control.
2. Video control reset its hiding timer due to the mouse event.
3. Video control update the progress bar while it is visible and cause a page relayout
4. go to step 1
So the video control never hide it self. Step 1 was introduced by the CL that mentioned above. Previously, we don't have step 1. So it was working fine.

It looks like using a (-1, -1) position for MouseLeave event can break the loop (perhaps by not reset the hide timer if the position is out of bound). 

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

commit 769a874fb57870662933ad0a7083b4e50c838149
Author: Biao She <bshe@chromium.org>
Date: Fri Sep 29 22:10:47 2017

Fix fullscreen video control visibility in cinema mode

With blink feature UpdateHoverPostLayout turned on, a MouseMove event will
dispatched post a Layout. Sending a mouse leave event at 0,0 will result
continuous MouseMove events sent to fullscreen video (as video continuous
relayout itself due to updating video progress in controls). This results
video controls always visible when in fullscreen VR mode. This CL should
fix it.

Bug:  762573 
Change-Id: I22eb20aef6d2216e68aa615e9b08aca811d40fd7
Reviewed-on: https://chromium-review.googlesource.com/693154
Commit-Queue: Biao She <bshe@chromium.org>
Reviewed-by: Amirhossein Simjour <asimjour@chromium.org>
Cr-Commit-Position: refs/heads/master@{#505461}
[modify] https://crrev.com/769a874fb57870662933ad0a7083b4e50c838149/chrome/browser/android/vr_shell/vr_shell_gl.cc

This fix only affect VR. I think it shouldn't cause any issue. Even if there is an issue, it should be VR only and wont affect mainline Chrome.

It should be pretty low risk to merge if we can still merge. Thanks!

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sorry for the noise. After offline discussion, it is fine to fix this in M63. So removeing merge request

-hotlist too

verified in 63.0.3233.0