I'm pretty sure I've seen this before M71 but I didn't record proof, so not sure when it started.

+ericrk@ FYI

Do you know if VizDisplayCompositor is on when you see this?

Sounds like a weird interaction between scrolling and surface sync irregardless

I didn't turn it on, it's not in stable right? And my past memory of seeing this suggests it doesn't need OOPD

I think we need to clip the viewport as it scrolls and we're not, so we see the bottom of the tiles coming into the viewport.

Unable to reproduce this issue on Pixel 2, attaching video for reference.

@danakj: Could you please check the screencast and let us know if we miss anything? 

Thanks!

Your version of chrome looks like its very different than mine. You have controls on the bottom that I don't, and the omnibox hides with an animation instead of with the scroll...

That said it looks like in your version there's some garbage content exposed behind the omnibox instead of at the bottom when it hides.

I can reproduce this as in #1 on this morning's ToT (8269a093f20adb3283259f9de27dc76e6d40cf25)

Both with VizDisplayCompositor on/off. We've been running Finch at 1% so I wanted to make sure this wasn't a side effect.

I don't have the animation in #7, and am not sure what flags control that.

I'll take a quick look at the delivering of top bar controls info to cc.

Will need to debug exact cause/fix closer.

But RenderWidget::SynchronizeVisualProperties is not being called until after the scroll ends. Which prevents "browser_controls_shrink_blink_size_" from being updated to reflect needing to resize the area.

As per c#8 removing Needs=Feedback label.

+mdjones@ whom added the relevant code.

What is happening is that ChromeFullscreenManager::updateViewportSize does not update the renderer while gestures/scrolling occurs. So while it eventually says to resize, this is after the scroll has completed. Leading to old content being shown for a tiny view.

Additionally it currently waits for the controls to be 0 height.

I have a partial fix up: https://chromium-review.googlesource.com/c/chromium/src/+/1387945/

But it seems to be too slow. A few frames of old content are still shown for a fast swipe. We might need to consider some sort of overdraw region to avoid this. However I'm not familiar enough with this area of the code, so all thoughts are welcome

Attached is a slow-mo version to demonstrate the effect 

Deleted: IMG_6142.MOV 27.6 MB

IMG_6142.MOV 27.6 MB Download

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

commit 935a93c49632893f361b71ae14359097da262578
Author: jonross <jonross@chromium.org>
Date: Thu Jan 17 17:39:16 2019

Partial Fix to Android Omnibox scrolling revealing other content

ChromeFullscreenManager::updateViewportSize calculates the changes in control
offsets, and determines when to toggle the resizing of the renderer's view.

Currently all viewport updates are blocked while a gesture or scrolling is
occurring.

This change updates the method to also perform the update if we've changed the
resize state. Allowing the renderer to resize to account for the larger region
when scrolling the controls away.

While this prevents showing older content, it only does so for normal speed
scrolls. A quick flick can lead to such a rapid change in viewport, that we
still have some frames of old content.

Bug: 916144
Change-Id: Ibbf8d6daa89691945e011022f9509fea4783cfe2
Reviewed-on: https://chromium-review.googlesource.com/c/1387945
Reviewed-by: agrieve <agrieve@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623741}
[modify] https://crrev.com/935a93c49632893f361b71ae14359097da262578/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/ChromeFullscreenManager.java

So aside from the super quick flick as seen in #12 this is fixed.

#12 occurs as we end up re-positioning the controls faster than we can update the viewport. I think we'd need to extend the surface beyond the region given to the page. So that we can have some extra region that matches the background colour. While not allowing the page to use the pre-paint area.

However I'm not familiar enough with this area of the code to know if that would be a correct solution.

mdjones@ would that be a correct path? If so whom would be most appropriate to take a look?