Just to update the latest behaviour,

Still able to reproduce the issue on Mac 10.12.5 using latest chrome version #61.0.3145.0.

ccameron@ - Gentle Ping...!!
Could you please have a look into the issue as it has been marked as a stable blocker.

Thanks...!!

This doesn't sound like a P1/stable blocker to me.

This is still in my queue.

Unlikely that this is related to the NTP. Removing NTP component.

This still reproduces on M60 but not on Canary -- I think that the fix for  issue 739621  accidentally fixed this (but didn't hit the root cause).

This is an issue with how we save off the background color that we then restore, at
https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_manager.cc?rcl=0b6316617d53a31cf7e52320845833806fbc84cd&l=2198

In this sequence of events, the "old" RHWV never actually got a frame, and so its background color is meaningless (happens to be initialized as "transparent", since that's consistent with the background CALayer of the RWHVMac).

We then pass this color down to the renderer, which starts producing transparent-background frames (because we told it that the background was transparent).

I've put together a patch that re-separates the concept of "background color from the renderer" and "is on an opaque background as specified by the embedder" at least for Mac. These two concepts shouldn't be conflated.

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

commit bb022357740c88dde09d3d2de6fd364c515714c2
Author: Christopher Cameron <ccameron@chromium.org>
Date: Thu Aug 10 10:05:42 2017

mac: Fix incorrect transparent background color

This makes a distinction between
- the background color for interstitial flashes when content isn't
  available
- whether or not the background of the page is opaque

Then, it ensures that whenever the background color is being queried
to be used as an interstitial background color, the result always be
opaque.

It may be a decent follow-on exercise to this would be to break
RenderWidgetHostView::SetBackgroundColor into two functions, namely
- RenderWidgetHostView::SetBackgroundIsOpaque
- RenderWidgetHostView::SetInterstitialBackgroundColor
This would clarify the only contexts in which the interstitial
background color is to be shown, and divorce it from opacity (the color
is not to be shown while the content is shown).

While we're in the neighborhood, get rid of the values that were setting
and returning from -[NSView isOpaque]. Our NSViews are layer hosting, so
opacity of the view is completely disregarded (the alpha channel of the
IOSurfaces we use is always read and used for transparency).

Bug:  735407 
Change-Id: I8b31fd81650421182842e5bb53215fc3c8067bd0
Reviewed-on: https://chromium-review.googlesource.com/607608
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493345}
[modify] https://crrev.com/bb022357740c88dde09d3d2de6fd364c515714c2/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/bb022357740c88dde09d3d2de6fd364c515714c2/content/browser/renderer_host/render_widget_host_view_mac.mm
[modify] https://crrev.com/bb022357740c88dde09d3d2de6fd364c515714c2/content/browser/renderer_host/render_widget_host_view_mac_unittest.mm
[modify] https://crrev.com/bb022357740c88dde09d3d2de6fd364c515714c2/content/browser/web_contents/web_contents_view_mac.h
[modify] https://crrev.com/bb022357740c88dde09d3d2de6fd364c515714c2/content/browser/web_contents/web_contents_view_mac.mm