This issue reproduces on OS X 10.12 but not on OS X 10.11.
It is related to setAutoDisplay: in BridgedNativeWidget::OnVisibilityChanged()
https://cs.chromium.org/chromium/src/ui/views/cocoa/bridged_native_widget.mm?q=bridged_nat&sq=package:chromium&l=913

It can be fixed if we call [window_ display]; after the call [window_ setAutodisplay:YES]; but I don't know why.
I tested it on seeing the following comment in WebKit:
https://webkit.googlesource.com/WebKit/+/b11e7874ca019b0218066e938b93574cdd423e10/Source/WebKit2/ChangeLog#14690

Or it also can be fixed if we do not call [window_ setAutodisplay:window_visible_]; and I don't know why it is necessary here.

in the past, the layer()->SetVisible(..) call (with false) higher up in OnVisibilityChanged would cause the contents to disappear/paint white during a minimize animation. If that no longer happens, it might be something changed in 10.12, or something changed around how ui::Layers work so that that no longer happens.

If 10.9 is fine without it, and no tests fail, it should be fine to remove.

layer()->SetVisible(false) is causing the contents to disappear/paint white during a minimize animation even with [window_ setAutodisplay:window_visible_]. I tested it on 10.12 and 10.11.
How about not to call layer()->SetVisible(window_visible_) when window_visible_ is false. I think layer() can be remain visible when window_ is invisible.

> layer()->SetVisible(false) is causing the contents to disappear/paint white during a minimize animation even with [window_ setAutodisplay:window_visible_]. I tested it on 10.12 and 10.11.

This should be fixable. We might need to delay the call to setAutoDisplay:true until BridgedNativeWidget::AcceleratedWidgetSwapCompleted(), or find some other way to suppess showing the blank layer. Otherwise, somehow block the deminiaturize animation from commencing with BridgedNativeWidget::MaybeWaitForFrame()


> How about not to call layer()->SetVisible(window_visible_) when window_visible_ is false. I think layer() can be remain visible when window_ is invisible.

I think this will cause tests to fail. And there are downsides - we still want to free up resources and suppress paints while the window is minimized. However there is also "occlusion" which feeds through differently on Mac, but AFAIK just for web contents (i.e. NSWindowDidChangeOcclusionStateNotification and RenderWidgetHostViewMac::Was[Un]Occluded(). If we can use occlusion to fulfill the same {free resources,suppress repaints} requirement on Mac function (rather than setting the layer invisible), then we might be able to justify leaving the layer visible.

But I suspect NSWindowDidChangeOcclusionStateNotification is asynchronous and won't satisfy all the requirements -- we still need to "Freeze" window display calls somehow.

MacViews triage: assigning to sdy@ for M-68 fix.

** Bulk Edit **

FYI: Starting 04/13 M68 will be in canary, M68 Dev promotion will be on 04/26.

Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.

This seems to be fixed.