ccameron: Is this a new known issue? Could it be caused by surface sync?

This is likely due to how we handle the question "what is to be drawn when there is no web contents" -- we keep a solid color CALayer in the background, and it is likely to be flashed up at various points (during navigation or tab switch).

I can reproduce it also on macOS 10.12.6 with latest Canary 67.0.3362.0.

I still see this on Canary 67.0.3369.0. Any updates on this? Feel free to cc more people if you'd like to. I don't know many mac experts myself.

Maybe a bisect can help to find the culprit CL.

Able to reproduce the issue on mac 10.13.3 using chrome reported version #66.0.3359.0 and latest canary #67.0.3370.0. Issue is not seen on OS-win and OS-linux.
But the issue seems to be very inconsistent in nature. Hence, it won't be possible from TE-end to provide bisect results.
Marking it as untriaged for further inputs from UI>Browser>Navigation team. Requesting someone from UI>Browser>Navigation team to please have a look into the issue.

Thanks...!!

I'm guessing we're swapping Viz displays on navigation?

This has nothing to do with compositing -- this has to do with  issue 470669 .

Check out the attached video, which shows CALayer borders -- you'll note that the flashed frames have no borders. This is because they don't come from web contents.

The black background flash comes from this code:
  content::RenderWidgetHostViewMac::SetBackgroundColor(
  content::RenderFrameHostManager::CommitPending(
  content::RenderFrameHostManager::CommitPendingIfNecessary(
  content::RenderFrameHostManager::DidNavigateFrame(
  content::NavigatorImpl::DidNavigate(

If we get rid of the SetBackgroundColor call in RenderFrameHostManager, then the issue goes away. I've generally not been a fan of doing this SetBackgroundColor on Mac, because Mac manages to set the background color to the theme background color, which is an "appropriate" color to flash.

I also don't know where the white flash during back-navigation comes from. It's likely coming from some NSView above the RenderWidgetHostViewMac.

Deleted: flash.mov 1.6 MB

	flash.mov 1.6 MB View Download

Thank you for investigating! The call to SetBackgroundColor in CommitPending explains the black flash, but it's been there for about a year so I'm wondering what changed recently that caused the white flash. I thought the white comes from the background color of the page we're switching to, but I installed a black theme and now the flash is black. Maybe we always had this transition from theme color to the background color of previous RWHV but now somehow a delay is introduced between these two operations and the flash becomes visible.

Is this something actionable / we have resources to fix?

Friendly ping to get an update on this issue as it is marked as stable blocker.

Thanks..!

Assigning to ccameron@ for triage.

I'm quite content to put a #if !defined(OS_MACOSX) around the line at [1] to fix this.

chrishtr, are you okay with that?

[1] https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_manager.cc?rcl=7cd4a5c57fc201c927c3b2b8e63f66c64631e8a3&l=2151

I'm not really in favor of that change. Changing to theme color then the final color
is worse than retaining the old site's background, then switching to the new site's background.

Regarding the white flash, I can reproduce it on Beta M66, and on Dev 67.0.3377.1 on Mac / Retina.

However, I was unable to reproduce it on Canary 67.0.3381.0 or 67.0.3383.0. Looks like the
white flash problem has been fixed.

I'm bisecting now.

Bisect results:

https://chromium.googlesource.com/chromium/src/+log/82d6c04085c29299159f31ed9c05349929064c84..2d6ef1d43652418e987ce20f6afcb38891d423a9

Chris, turns out you fixed it already :)

https://chromium.googlesource.com/chromium/src/+/290d8214f8b1a1306370e3ab2b74fa5acae58500

I'm very scared that that patch had any functional effects ... it wasn't supposed to!

Feels suuuuper racy.

Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks! 

I don't think this should be RBS
- it's fixed and the fix is not exactly portable
- it's fairly minor

Re #18:
> I'm not really in favor of that change. Changing to theme color then the
> final color is worse than retaining the old site's background, then switching
> to the new site's background.

The original about flashing was about users with dark themes seeing flashes -- it was not about "oh, I'm at one dark page and going to another, and I want to avoid seeing the theme background color".

We only did the hack where we save off the old background color because Aura was unable to plumb the theme color through from the browser window to the WebContentsView/RenderWidgetHostView.

The fix proposed in  issue 815187  (just keep the old contents around longer) also does seem reasonable.

Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug. 

To reiterate #22
- I don't think this should be RBS
- If we do want to do something for 66, my suggestion is to eliminate the "save off the old color and apply it to the new page", since it's unnecessary on Mac

We have a good fix for this behavior coming in 67.

Is it not possible to merge #19 into m66?
Anyways, removing RBS per ccameron's comment.

The change from #19 is part of a long chain of patches, not a good candidate for a merge.