Please find the log and Video @ http://go/chrome-androidlogs1/8/888964

Per-CL bisect information:
Good commit:589184
Bad commit:589185

Suspect CL:
https://chromium.googlesource.com/chromium/src/+/62898a131761fbeeac3f2b2f7c2c0512f7ca14a9

dtapuska@  Might be it looks like this issue is related to your change. please look into once, if its not related to your change please reassign back to me. 

Thanks!

Bo, Frank any ideas? I can occasionally reproduce this on a Nexus 5 but always on a Pixel2. Seems like a timing issue and the position of layers. It fixes upon rotation.

i suggest turning off overlays (--disable-features=overlay-fullscreen-video) and see if it still happens.

I believe Android WebView already disables both here: https://cs.chromium.org/chromium/src/android_webview/lib/aw_main_delegate.cc?type=cs&q=UseAndroidOverlay&g=0&l=173

Oh, no sorry those are other switches. Will try disabling it for webview...

It still happens with setting that flag to disable overlay fullscreen video

sorry, i missed that this was webview.  yeah, it's off for webview all the time.

not sure.  a few things come to mind:

- full screen transitions can push a scroll offset to the impl side of the cc tree, if i remember.  maybe something's going wrong there.  not sure why it would affect the video layer only, though.

- full screen transitions in the browser roughly start here, to send the updates to the renderer: https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_android.cc?rcl=9ed601294506de71433e1cb9c32a2d33cce558d2&l=1225 .  it might be interesting to compare the order of calls between a 'working' and 'non-working' transition.

caveat: this was a long time ago, and i think i've actively tried to forget how it all worked.  :)

Wow that looks odd. Webview disables kUseSurfaceLayerForVideo as well, in case that matters. This looks to be blink putting the video in the wrong place (assuming no compositing bug)? I have no knowledge at all about blink things..

eae@ can I get some help form a layout perspective? I don't believe it is a CC issue but actually a layout issue. I find that when I set the "object-fit: fill" style on the video element it works correctly. Alternatively I can set the "top: -516px" or so to move it up and it renders correctly.

I'm not sure if this is a site issue or a layout issue. Being that it works sometimes and not others I wonder if it is a layout issue. I'll try comparing styles when it works and when it doesn't. 

I don't suppose there is any way to reproduce this without a Pixel 2 device and the Bing app?

I went through all changes in the regression range and the following two stand out:

- r589275 Changes how scroll positions are computed and is the only layout
          change in the regression range.
          https://chromium-review.googlesource.com/1181644

- r589190 Changes how scroll positions are restored on existing fullscreen.
          https://chromium-review.googlesource.com/1195714

The second one in particular seems relevant.

The change clearly bisects to my change enabling the feature flag. But I believe that this actually reveals a possible race (or problem handling the Pseudo Fullscreen selector)

It occurs on a Nexus 5 as well but only in the bing app. I'm working on dumping the layout tree cause devtools doesn't reveal much to me.

Ah, didn't realize that. Thanks for the clarification.

It's certainly possible that the timing of the scroll computation is incorrect after exiting fullscreen, this code is sadly full of life-cycle violations. Enabling the feature might very well have triggered a code-path that wasn't executed before and thereby surfaced an existing problem.

szager (cc:ed) is the person with the best grasp of these things.

Debugging inside of webview, in the bing app, on an external device certainly makes for an interesting challenge!

Hmm.. looks like it is the height of the video layer..

When it fails:
layer at (0,144) size 1080x1548 backgroundClip at (0,144) size 1080x608 clip at (0,144) size 1080x608
  LayoutVideo (positioned) {VIDEO} at (0,0) size 1080x1548

When it is working:

layer at (0,144) size 1080x609 backgroundClip at (0,144) size 1080x608 clip at (0,144) size 1080x608
  LayoutVideo (positioned) {VIDEO} at (0,0) size 1080x609

Yet the style specifically has height: 516px applied to it.

szager@ do you mind taking a look based on comment #15. I'm OOO for a few days.

The video element has an inline style declaration that sets its width. The page script has a resize event handler that runs code to update that value. So, I think this needs to be fixed in javascript. I cross-filed this in YouTube's bug tracker:

b/117182231

Re comment #17 -- it's the inline style 'height' value that is problematic, not 'width'.

Removing the RegressedIn and ReleaseBlock flags; this needs to be fixed on the YouTube side.

Issue 907431 has been merged into this issue.