I bisected this to r463127, so it regressed in M59. I'm not sure how bad the impact is, but we should try to fix this on trunk soon and think about potentially merging this to M59 and M60.

Guessing this falls under Blink>Paint?

Possible reliable repro:

(1) Open 10 new windows
(2) Open 1 more new window, and open a PDF there
(3) Open a new tab
(4) Switch back to the tab with the PDF. I usually hit ctrl + PageUp if that makes a difference.

Adding release block stable, since this is a new regression in m59. 

We've had a very similar issue that was due to related changes to base background colors a while ago, see  https://crbug.com/708445 .

I was able to repro locally, and removing the early-outs in WebViewImpl::Set/ClearBaseBackgroundColorOverride() and LocalFrameView::SetBaseBackgroundColor() does resolve the issue. This helps, because RenderWidgetHostImpl sends an IPC (ViewMsg_SetBackgroundOpaque) when it is shown (i.e. a tab switches back to it), which calls either ClearBBCO or SetBBCO, which end up calling LocalFrameView::SetBaseBackgroundColor(), which forces a SetNeedsDisplay() on the frame's main graphics layer.

I don't think that removing the early-outs is the right fix, though - as the base background color doesn't change. It is likely that something else happens during switching the tab that *should* trigger a SetNeedsDisplay() (or setNeedsCompositingUpdate()?), but doesn't currently.

Chris, do you have any guesses what that might be? It's interesting that this seems to only be an issue when there are lots of tabs/windows.

FYI, this doesn't only affect the pdf-tab. If I repro using the steps in #3, but open a tab to about://blank in step (3), switching back from the pdf-tab to the about://blank tab shows a dark gray/black background instead of the default white one, see video.

Deleted: capture.webm 5.2 MB

	capture.webm 5.2 MB View Download

It seems that the renderer doesn't submit a new CompositorFrame to the browser after becoming visible in these situations. Is this something the browser should support, e.g. by displaying an old CompositorFrame (from before being hidden) for the renderer? (If so, the bug must lie somewhere in the browser.) Or should a renderer be forced to submit a new CompositorFrame when becoming visible after being hidden? (This is the effect of removing the early outs.)

I believe the reason we are seeing different background colors depending on which page was switched from/to is this: https://cs.chromium.org/chromium/src/chrome/browser/ui/browser.cc?type=cs&sq=package:chromium&l=1049.

It seems the browser renders only the background color copied from the previous tab instead of the new tab's contents. I'm going to assume that's because it doesn't receive a new CompositorFrame from the new tab's renderer, but (for some reason) already got rid of its last CompositorFrame. Not sure whether that may be affected by how many windows/tabs are open.

jbauman@ confirmed that the browser expects a new CompositorFrame after showing a RenderWidget (because it may drop CompositorFrames of hidden tabs, particularly if there are many tabs/windows). Seems we need to enforce that somehow.

Sending https://chromium-review.googlesource.com/c/528233 to fix.

It turns out that the reason this normally works is that the impl-thread compositor requests new tiles when becoming visible, and produces a new CompositorFrame after the tiles are prepared. If, however, there are no tiles that need preparing, no CompositorFrame is produced.

Such a situation exists with about:blank, because there all quads are bgcolor-only. Similarly, because a pdf-tab consists of a parent renderwidget with only an embedded renderer, the parent also doesn't have any actual tiles.

Thanks for working on a quick fix! Just a heads up, we have a respin planned for Monday 6/12 and this is marked as a release blocker. We'll need to have a fix merged before Sunday 6/11 5pm (pacific). 

Provided we don't run into another issue with the fix, we should be able to land it today.

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

commit ba106147d5213d5ba8879bb210beefedbd476c94
Author: Eric Seckler <eseckler@chromium.org>
Date: Fri Jun 09 16:39:38 2017

[cc] Force viewport damage + redraw after showing LayerTreeHostImpl.

The browser expects a new CompositorFrame from the renderer after
showing it. If the renderer compositor has no actual (direct) content
and thus no tiles, it is possible that the renderer doesn't submit
this new CompositorFrame, which results in a blank page.

This patch ensures that a redraw will happen on the compositor thread,
even if there are no tiles.

Bug:  730848 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie6fbc2ceb05e7138fb9a44a848f5e1ebc7b36aa4
Reviewed-on: https://chromium-review.googlesource.com/528233
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#478303}
[modify] https://crrev.com/ba106147d5213d5ba8879bb210beefedbd476c94/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/ba106147d5213d5ba8879bb210beefedbd476c94/cc/trees/layer_tree_host_impl_unittest.cc

Only requesting merge for m60 for now. The change should be safe, but maybe we want to wait a day or two before merging into m59 to be more confident?

Since M59 stable is coming up on Monday, maybe consider requesting a revert of the original patchset for M59 instead.

I don't think that's a good idea. The original patch set was fixing different kinds of bugs - see  issue 708445 . Reverting it would be more risky than merging the fix in my opinion.

Oh ok, was just a suggestion based on the fact that r463127 only mentions  issue 689349 .

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

Approving merge for M60. 

I've approved the merge for M60. Please confirm if you're confident with this change for M59. We're planning a respin for tomorrow, 6/13 and will need to get this fix in by 4PM today Monday (pacific). 

I haven't seen any issues on canary so far, so would be ok with merging into M59 as well.

(Let me know if you'd like to wait for a day on Dev though.)

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

commit 7c943d215eb172f8292fd6a593f373e7d5cc4607
Author: Eric Seckler <eseckler@chromium.org>
Date: Mon Jun 12 14:35:27 2017

[cc] Force viewport damage + redraw after showing LayerTreeHostImpl.

The browser expects a new CompositorFrame from the renderer after
showing it. If the renderer compositor has no actual (direct) content
and thus no tiles, it is possible that the renderer doesn't submit
this new CompositorFrame, which results in a blank page.

This patch ensures that a redraw will happen on the compositor thread,
even if there are no tiles.

TBR=eseckler@chromium.org

(cherry picked from commit ba106147d5213d5ba8879bb210beefedbd476c94)

Bug:  730848 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie6fbc2ceb05e7138fb9a44a848f5e1ebc7b36aa4
Reviewed-on: https://chromium-review.googlesource.com/528233
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#478303}
Reviewed-on: https://chromium-review.googlesource.com/531006
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#306}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/7c943d215eb172f8292fd6a593f373e7d5cc4607/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/7c943d215eb172f8292fd6a593f373e7d5cc4607/cc/trees/layer_tree_host_impl_unittest.cc

Thanks - approving for M59 based on canary results, safe merge, and well tested. Branch:3071

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

commit 404d6ba4012a81264ba819966a4fcae2cb931a01
Author: Eric Seckler <eseckler@chromium.org>
Date: Mon Jun 12 15:04:09 2017

[cc] Force viewport damage + redraw after showing LayerTreeHostImpl.

The browser expects a new CompositorFrame from the renderer after
showing it. If the renderer compositor has no actual (direct) content
and thus no tiles, it is possible that the renderer doesn't submit
this new CompositorFrame, which results in a blank page.

This patch ensures that a redraw will happen on the compositor thread,
even if there are no tiles.

TBR=eseckler@chromium.org

(cherry picked from commit ba106147d5213d5ba8879bb210beefedbd476c94)

Bug:  730848 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie6fbc2ceb05e7138fb9a44a848f5e1ebc7b36aa4
Reviewed-on: https://chromium-review.googlesource.com/528233
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#478303}
Reviewed-on: https://chromium-review.googlesource.com/531245
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/branch-heads/3071@{#776}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}
[modify] https://crrev.com/404d6ba4012a81264ba819966a4fcae2cb931a01/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/404d6ba4012a81264ba819966a4fcae2cb931a01/cc/trees/layer_tree_host_impl_unittest.cc

Tested the issue on ubuntu 14.04 using chrome dev M61 #61.0.3028.0 and issue seems fixed as per the steps mentioned in comment #0 .

Attached screencast for reference.

Adding TE_Verified labels .

Thanks!

Deleted: 730848.ogv 10.7 MB

	730848.ogv 10.7 MB View Download

 Issue 730852  has been merged into this issue.

Tested the issue on Ubuntu 14.04 using chrome version 60.0.3112.32 as per the steps mentioned in comment #0 and #3.Not observed any white , gray or blank while switching from new tab to PDF.

Unable to reproduce the issue on Ubuntu 14.04 using chrome version 59.0.3059.0 as well.

Could any one please confirm if anything missed in verifying the issue.

Thanks,

Sounds good. I think that should suffice for verification, since the steps in #3 are a reliable repro and you now tested all affected branches, i.e. M61, M60, M59.

Rechecked the issue on Ubuntu 14.04 as per the steps provided in issue description and Comment#3. Unable to view grey or Blank pdf pages while switching tabs.

Adding TE-verified labels.

Thanks.!

 Issue 732096  has been merged into this issue.