over to mlamouri for triage.

I'm unable to repro this on ToT. control bar hides after a few seconds; it doesn't return unless I move the mouse. (linux)

Second try after ping from yiningc@ --
no repro ToT linux
I found *repro* on Windows Canary 63.0.3239.0 (Official Build) canary (64-bit) (cohort: 64-Bit)

Note, if I move the mouse to second window immediately after selecting fullscreen on Windows, then *no repro*.

Just some more data for mlamouri@'s triage.

Sounds like a fullscreen UI issue instead of media UI. foolip@, does that sound familiar?

I'm experiencing this on my mac laptop. 100% repro. I can try to help if you are unable to repro.

This makes Netflix unusable IMO, so upping the priority. We should make sure this doesn't make it to stable.

This is happening to me too (macOS 10.13). I think it should be a release blocker.

The bug probably is for all OS but for me it started with Chrome 62 not 63.

I get the bug with Linux kernel 4.4.92 using Chrome 62.0.3202.62

The bug goes away switching back to Chrome 61.0.3163.100

This issue is marked as a release blocker with no OS labels associated. Please add an appropriate OS label.

All release blocking issues should have OS labels associated to it, so that the issue can tracked and promptly verified, once it gets fixed.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

+xhwang,eric as fyi

If this bug repros on M62, M62 is already in stable. Hence, applying "ReleaseBlock-Stable"

It does exists on Latest Stable#62.0.3202.62. Let me narrow it down and find the culprit change.

Assigning to manoranjanr@ to bisect, please assign back to me if it was my fault.

This should not block this week's M-63 beta since the problem is already on stable. If it's a serious problem, then merging back to the next M-62 stable release would make more sense, but who is to make that call?

PS: 'bisect.py' is not of much help since 'Widevine' component update didn't work on those chrome instances.

Good#62.0.3186.0
Bad#62.0.3187.0

Here is the Change Log: https://chromium.googlesource.com/chromium/src/+log/62.0.3186.0..62.0.3187.0?pretty=fuller&n=10000

sdy@, can you please look into this change (https://chromium.googlesource.com/chromium/src/+/3d2cb7bc417d5ad462949ca8e512e45f6c71cdb8) if possible? Please feel free to re-assign in-case the change is not related.

Thank you!

I see this as well on Windows Chrome 64.0.3246.2, and in windowed mode too. 

Unfortunately that code is both Mac-specific and disabled behind a flag. This just started happening to me within the last few weeks, FWIW.

Our next M62 Stable Respin is planned for Wednesday 10/25. 

I reproduced this issue, and I think we should certainly treat this as a release blocker. Any chance we can have this issue fixed in the next 1-2 days?

dtapuska@: Could you take a look at this? I’m not sure, but after looking through the list of commits I have the tiniest hunch it could be this one: 2e27e8ef7352fa68de51b0c59257604c66b9781d

It would be good to know if this was reproducible or not with the --disable-blink-features=UpdateHoverPostLayout passed into the command line.

Yes, issue is getting disappeared w/ the above flag: --disable-blink-features=UpdateHoverPostLayout

We can probably pull the flag in Chrome 62 and try to fix it in Chrome 63 properly. I presume that the media controls are being shown due to the mouseover/out/enter/leave events that this change causes. I can prepare a patch directly on M62 to remove the flag tomorrow as it is past EOD here.

Removing the Beta blocker for M63 as it is being targeted for next M62 stable refresh.

Please adjust the label accordingly for M63 if the above plan changes.

It looks like these controls are solely handled by the netflix site and not our standard media controls. Has anyone been in contact with Netflix to see if this can be fixed on their end? I need to look at Netflix in Firefox and see if they are listening to the same events.

What is the bug/fix from Netflix's POV?

Sorry, I see the description in #25 — how *should* they be handling the media controls?

OK, there's an element on the page with the class "PlayerControls--container". In Chrome, the element gains the class "PlayerControls--low-power" when the controls hide, which gives it display: none and (now) triggers a mouseout event. (This is surprising to me, but I guess it's intended because Firefox behaves the same way.)

In Firefox, the PlayerControls--low-power class is never added. I haven't tried to track down why, but I assume that difference in behavior is on their end. Should our recommendation be be to ignore mouseout or ignore/remove the mouseout listener when applying this class?

Maybe this should be considered a Netflix bug.

I kinda reproed on 62.0.3202.62 on Mac, and what I saw is worse than the bug description. The cursor and the whole UI first disappeared after playback started, then came back ~5 seconds after, then they disappeared again, and then came back again, and so forth. I can repro this in fullscreen and non-fullscreen mode. Check https://youtu.be/Q--XeCrjVYo to see the video recording I took and let me know whether you see the same problem. I didn't touch the keyboard or the trackpad when I recorded the video.

I will reach out to Netflix so they can also look into this from their side.

This happens on Chrome OS 62. It appears to stop happening if you put your mouse in the top right corner, but that's an annoying thing to do:
https://www.giantbomb.com/forums/bug-reporting-33/time-video-control-bar-keeps-popping-up-fullscreen-1442041/?page=1#js-message-8705381

Re. #31, yeah, that's what I saw too. Sounds like this might be on Netflix to fix, so removing RBS.

I certainly am being served up different versions of the controls depending on what OS, browser combo I'm on. This doesn't repro on my Linux box but does on ChromeOS. Any word from netflix?

update from NFLX : we are aware of this bug and a fix is being tested for release this week. We may need a followup regarding some odd behavior of DOM elements firing events when setting display: none.

It might be worth sending them:

- https://www.chromestatus.com/features/5687758374830080
- https://docs.google.com/document/d/1TgqvDg8L_TkEiNjBUaz39FDgxpp5aj9ZdIWeQSanKHY/edit

(The second link specifically explains the display: none behavior.)

Seems like 'Netflix' has released the fix? I do not see this issue anymore.

netflix pushed a fix out this afternoon. Archive this one since it was a NFLX fix?

I concur that Netflix fixed it.
The issue is now gone on my Linux system with Chrome 62.0.3202.62

SGTM