+sky@ who knows this better.

NativeViewHost::OnPaint has the following code.

  // The area behind our window is black, so during a fast resize (where our
  // content doesn't draw over the full size of our native view, and the native
  // view background color doesn't show up), we need to cover that blackness
  // with something so that fast resizes don't result in black flash.
  //
  // It would be nice if this used some approximation of the page's
  // current background color.
  if (native_wrapper_->HasInstalledClip())
    canvas->FillRect(GetLocalBounds(), resize_background_color_);

which breaks the background even if the content is transparent. Removing this fixes the issue.

I believe this is for legacy views (because the area behind isn't black in aura),
and is no longer necessary in aura.

sky@, let me know if I'm wrong.

I'm pretty sure the fast resize path is still there. The fast resize path is triggered when you toggle the bookmark bar. You can see the content doesn't resize until the animation is done.

If this is causing a problem some then perhaps the code could set the resize_background_color_ to totally transparent. I'm equally ok with making the default transparent and having WebView initialize the background color to white as I think WebView is the only place that really needs this.

Sorry if it wasn't clear. I'm not suggesting to remove fast resize.

My point is that there should be no need to fill the background, because that area is covered by another layer which should be filled by compositor.

My understanding is that the background color predates aura, and was added to hide the black-hole, which does not happen in aura.

Not sure what you mean? NativeViewHost itself does not have a layer, and the nativeview (aura::Window in this case) is being positioned in such a way that it doesn't fill the NativeViewHost's bounds.

I looked into it and I now understand that this is still necessary when the native view is supposed to be opaque.

For aura, we can automate this by checking layer->fills_bounds_opaquely() and skip filling the background (as someone else must already be drawing background), but i guess this may not work well on mac.

By the way, NVH does fill the background even if it's not in fast resize mode, and that was causing the issue. Looks like it's a bit hard to change this to happen only in fast resize, but if you have an idea, let me know. Otherwise, I'll  update the fast resize background color.