Evict Surfaces from Before Navigation When Re-using DelegatedFrameHost
When we are not applying site-isolation a DelegatedFrameHost can be re-used when navigating between different pages. This can occur on Android as well as with the un-supported flag --disable-site-isolation-trials. When RenderWidgetHostImpl::ForceFirstFrameAfterNavigationTimeout is invoked, as either from tab-changing, or from thumbnailing, we set fallback surfaces. This is intended to be the first viz::SurfaceId that was generated by navigation. However if a navigation fails we don't actually embed a new surface. The DelegatedFrameHost then ends up utilizing outdated surfaces as the fallback. This change updates DelegatedFrameHost to be notified of when a navigation begins. If we fail to embed a new surface by the timeout, we evict the surface that predates the navigation. The ThumbnailTabHelper has been updated to also clear its currently cached thumbnail in the case that the page has transitioned back to the unready state. Thus clearing thumbnails that exist from before a navigation. TEST=NoCompositingRenderWidgetHostViewBrowserTest. NoFallbackAfterHiddenNavigationFails Bug: 1152894 Change-Id: Ia5734abb5201a56c271114a891bc81212a3aa975 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2585790Reviewed-by:Dana Fried <dfried@chromium.org> Reviewed-by:
Jonathan Ross <jonross@chromium.org> Reviewed-by:
kylechar <kylechar@chromium.org> Reviewed-by:
Collin Baker <collinbaker@chromium.org> Reviewed-by:
Bo <boliu@chromium.org> Commit-Queue: Jonathan Ross <jonross@chromium.org> Cr-Commit-Position: refs/heads/master@{#837779}
Showing
Please register or sign in to comment