Sorry, the about forgotten crx

Deleted: fullscreen-trouble.crx 2.6 KB

fullscreen-trouble.crx 2.6 KB Download

Problem persists on latest Cannary. Actually it got a little worse, because it crashes whole Chromium sometimes. 

+1

Able to reproduce the issue on the reported chrome 69.0.3497.100, latest canary 71.0.3556.0 using Mac 10.13.6. Below is the bisect information for same. 

Note: Issues not seen on Windows and Ubuntu.
Bisect Info:
================
Good build: 69.0.3446.0
Bad build:  69.0.3447.0

You are probably looking for a change made after 563064 (known good), but no later than 563065 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/fbf576282bc9b2281a6a2299883ef910c5d71e70..14eeb1d5b6369a4fefa57973bf6b646469f72e35

Suspect: https://chromium.googlesource.com/chromium/src/+/14eeb1d5b6369a4fefa57973bf6b646469f72e35

Reviewed-on: https://chromium-review.googlesource.com/1066600

Dave Tapuska:Please confirm the issue and help in re-assigning if it is not related to your change. Adding RBS label for M-70 feel free to change it if not required.

Thanks!

I can reproduce this but the fullscreen issue is only for video. Other content in fullscreen works correctly so I wonder if this is a timing issue on Mac with Webview.

+ccameron as I need some help with this as not sure how overlays for video in a webview work on Mac

I wonder if this is related to the Fullscreen Low Power mode on macOS. Couple of flags to try
  --disable-mac-overlays 
  --disable-avfoundation-overlays
If --disable-avfoundation-overlays alone fixes the issue, then this may have to do with fullscreen low power mode.

If it still reproduces with --disable-mac-overlays, then this is pretty far away from the unique parts of the mac video pipeline.

Hmmm.. might not actually be related to video at all.

If the webview app is maximized it works correctly. If it needs to resize the window it fails (even with other content).

I wonder if the browser is never generating a visual property item with fullscreen granted so then we are forever stuck in the transitioning state.

See:
https://cs.chromium.org/chromium/src/content/common/visual_properties.h?type=cs&g=0&l=68

Will debug more tomorrow.

I am still able to reproduce the issue with all possible combinations of suggested flags.

I'll investigate. I cc'ed a bunch of Viz folks.

Here is a simplier example URI that indicates BeginFrames stop occuring...

http://output.jsbin.com/mufiqoq

So I think this might be a visibility race.

If add if (!visible) return to the code here: https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host.cc?type=cs&g=0&l=641

It starts working.

A few findings...

I believe this is related to issue 865192
It works if --disable-features=WebContentsOcclusion is added to the command line

It appears that occluding makes this behave like hidden.. https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_mac.mm?sq=package:chromium&g=0&l=433

It is unclear why occulsion is being detected here.

Adding fdoray@ who wrote the occulsion support.

Ohh Ok, reassigning to fdoray@ then.

Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!

Mac triage: stripping target-69 since this most likely won't go into a 69 respin at this point.

[bulk edit] - This issue is marked as a stable blocker for M70. We are two weeks away from M70 Stable. Please take a look urgently!

Removing RBS tag. 

Any news? Now, isn't release block for v70?

Re. comment #11: I don't see the counter stopping when entering fullscreen. I'm only able to reproduce the issue in a Chrome app.

We have occlusion tracking on Mac since 2015 https://codereview.chromium.org/853883007.
My CL made low-impact changes to this code, which didn't cause this regression. This regression was caused by https://chromium-review.googlesource.com/1066600.

I'm currently investigating what changed with this CL in order to recommend a fix.