[Bulk Edit]
Applying M-68 milestone per email discussion with ellyjones@. Pls change it if milestone is incorrectly applied. 

MacViews triage: the entire *window* is white until the deminiaturize finishes, which is a regression from the Cocoa window. Assigning to robliao@ for M-68.

** 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.

Can we please remove " Sprint-1" label as " Sprint-2" is already applied at #8?

Yep. I was trying to figure out how to mass-remove labels but couldn't find a way how.

Ok, got it. Removing "Sprint-1" label per comments #9 & #10.

Any progress here?

Nope. Starting the investigation now.

It's not just the top bar. It looks like any views control handled by BrowserView exhibits this behavior. For example, the downloads bar on the bottom also renders write briefly.

 Issue 839756  has been merged into this issue.

I suspect this is happening due to some weird stuff in NativeWidgetMacNSWindow's orderWindow: override. OR because said "weird stuff" is currently missing from the restore-from-deminiaturize codepath/flow coming from AppKit.

In early testing, this deminiaturize animation worked correctly when NOT using layer-backed windows (i.e. when going through the now-nonexistent -BridgedContentView drawRect:..])

Things since switched exclusively to layer-backed windows.

It's possible we need to block for a frame in the deminiaturize codepath.

OR there's possibly cause to do something smarter with the layer when miniaturizing.

On Aura platforms, the expectation is that the layer is made invisible on minimize. MacViews does this (otherwise some tests fail), and does it in a way so that the image captured by AppKit for expose is not udpated beforehand.

I think we can "fix" this simply by never making the layer invisible, and responding to updateLayer requests. That may be closer to what AppKit expects to happen.

But, ideally, we still make the layer invisible on miniaturize, but figure out how to respond to an udpateLayer request (and possibly block for a compositor frame) before the UI-thread-blocking deminiaturize animation kicks in. (OR figure out how to get AppKit to use the image captured when the window was miniaturized, but and update it at the end of the deminiaturize animation).

Note you can also see this `half-fixed` by holding down "shift" to slow down the deminiaturize animation. Note Apple removed this effect in 10.13, but you can re-enable it

https://apple.stackexchange.com/questions/303106/how-to-enable-slow-genie-effect-in-macos-10-13-high-sierra

in this case, the animation goes slow enough that the MacViews UI layer *does* paint early on in the deminiaturize animation. That suggests we just need to block for a few milliseconds before the animation takes over the UI thread and we can no longer swap in a frame.

(ideally we don't block UI threads, but the AppKit animation blocks already for *ages* so a tiny but more probably won't matter).

M68 branch is coming soon on this Thursday, 05/24 and M68 Beta promotion is on 06/07. 
This bug is marked as P1 for M68. Pls land the fix to trunk ASAP (if possible before 4:00 PM PT this Thursday in order to make it to M68 branch build cut. Thank you.

M68 Beta promotion is coming soon on June 7th. Pls land the change to trunk ASAP and request a merge to M68 by EOD, this Friday (06/01). So we can take the merge in for M68 beta promotion to run 50% experiment. Thank you.

If this is indeed a blocker for M68 50% beta experiment, pls land the change to trunk and request a merge to M68 ASAP. Thank you.

Note: M68 is going to beta tomorrow (06/07).

Any progress here as this is marked as P1 for M69?

Stealing this one as I think I have a fix for it.

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

commit bdd9c892c625154a24629b59c2eb117b4c41b538
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Jul 11 16:21:11 2018

MacViews: Don't draw blank windows after de-miniturize

Whenever the ui::Layer for BridgedNativeWidgetMac is hidden, also lock
the ui::Compositor ("lock" in this sense means "disable drawing new
frames").

This ensure that we won't draw any blank frames (which is what would
result in a blank frame).

Bug:  712244 
Change-Id: Ia8c17742e6a48190b9a3aead6443102a585d1f7d
Reviewed-on: https://chromium-review.googlesource.com/1129320
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574187}
[modify] https://crrev.com/bdd9c892c625154a24629b59c2eb117b4c41b538/ui/views/cocoa/bridged_native_widget.h
[modify] https://crrev.com/bdd9c892c625154a24629b59c2eb117b4c41b538/ui/views/cocoa/bridged_native_widget.mm

 Issue 792707  has been merged into this issue.

Able to reproduce the issue on chrome version# 69.0.3480.0(build without fix)
Verified the fix on Mac 10.12.6 on chrome version# 69.0.3489.0 as per comment# 0
Attached screencast for reference.
Observed "On deminiaturising the chrome from dock white screen is not seen"
Hence, the fix is working as excepted
Adding the verified label.

Thanks!

Deleted: 712244.mp4 3.7 MB

	712244.mp4 3.7 MB View Download

 Issue 852461  has been merged into this issue.