Thanks Robert!

Yea, this came up in https://codereview.chromium.org/2069103004/#msg4 BridgedNativeWidget::ShowAsModalSheet() actually already has a fix plumbed through for modal window sheets (the sheet animation is synchronous, so if it starts blank it stays blank until the animation is finished).

Just need to apply that to regular windows too at the "right" place..

So that we don't forget, setting the window alpha to 0 before displaying and setting it back to 1 when frames from compositor arrive, might fix this.

Yep - I like that idea :). I think it's nicer than blocking the UI thread - we care a lot about performance on this codepath, and this might be a cool way to keep everything busy, e.g, during browser startup (in the general case -- not just task manager).

It's a bit sneaky... and there are some downsides. E.g. the transparent window will be clickable for the 10-200ms it takes for the frame to arrive - possibly longer under load (e.g. Desktop restore). There are ways to ignore the events though.

Also it may transfer a bit of extra load to the WindowServer, or there may be measurable latency in the call to make the window opaque again that we need to take into account. But in the grander scheme of the crazy things we do to get AppKit to cooperate with render frames, making the window invisible seems pretty mild.

I think tab modal dialogs (like the collected cookies dialog) on Cocoa, also just set the window alpha to 0, instead of doing an orderOut: on tab switching. (Relevant code is probably in ConstrainedWindow... classes). Maybe we can look at what they do.

Right, the ConstrainedWindows both set alpha to 0 and setIgnoresMouseEvents:YES:

https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/constrained_window/constrained_window_custom_sheet.mm?dr=C&sq=package:chromium&l=80
https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/constrained_window/constrained_window_sheet_info.mm?sq=package:chromium&dr=C&l=42

patricialor@, can you take a look at this? If not feel free to bounce it back to Untriaged :)

It looks like this doesn't happen any more - I bisected the fix down to tapted@'s CL https://crrev.com/410012 (54.0.2821.0). I've attached a screencast & screenshot of what happens now - the grey has been replaced with white, which is much less noticeable when the content appears on top of that. Interestingly, there are black squares in the bottom two corners (see screenshot), which karandeepb@ doesn't see with the same repro steps - does anyone know anything about this?

Will mark this as fixed now.

Deleted: Screen Shot 2016-08-17 at 15.33.28.png 20.4 KB

	Screen Shot 2016-08-17 at 15.33.28.png 20.4 KB View Download

Deleted: whitewindow-2821.mov 523 KB

whitewindow-2821.mov 523 KB Download

So I tried again and I do see the black squares at least when resizing the dialog. 

I can still notice the white :(. Cocoa doesn't paint with these weird flashes, so I think we should try and not have any.

Screencast for http://crrev.com/2312133002.

Deleted: task_manager_flicker.mov 4.5 MB

task_manager_flicker.mov 4.5 MB Download

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

commit f6ac68b04228683aa3176ad4020e109fbde5abf6
Author: karandeepb <karandeepb@chromium.org>
Date: Mon Sep 12 01:42:45 2016

MacViews: Fix flashing of opaque non-modal windows on display.

Currently, opaque non-modal windows like the Task Manager appear with a "flash",
when displayed initially. This is because if the frame from the compositor
hasn't arrived yet, the background color of the window shows through. When the
frame arrives, the actual contents are displayed, causing a "flash".

To get around this, for opaque non-modal windows, set the alpha value of the
window to 0, till the correct frame from the compositor is received. Also,
ignore mouse clicks till then. This also fixes the "black strip" that is
displayed in the non webcontents area of the MacViewsBrowser, when it is
displayed initially.

BUG= 623950 ,  645343 
TEST=With chrome://flags/#mac-views-native-dialogs enabled, open the Task
Manager. Observe it is not displayed with a Flash. (Record a screencast and
observe frame by frame).
TEST=Build with mac_views_browser=true. Open the browser and observe no black
strip is displayed in the non web-contents area, when it is displayed initially.

Review-Url: https://codereview.chromium.org/2312133002
Cr-Commit-Position: refs/heads/master@{#417863}

[modify] https://crrev.com/f6ac68b04228683aa3176ad4020e109fbde5abf6/ui/views/cocoa/bridged_native_widget.h
[modify] https://crrev.com/f6ac68b04228683aa3176ad4020e109fbde5abf6/ui/views/cocoa/bridged_native_widget.mm

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

commit 4a528effa127e1db82476eeb57c57649664af9b5
Author: karandeepb <karandeepb@chromium.org>
Date: Tue Sep 20 08:33:56 2016

MacViews: Modify condition for setting window alpha to 0 on initial display.

r417863 added a flag initial_visibility_suppressed_ to BridgedNativeWidget to
show some dialogs with an alpha value of 0 initially, till the frames from the
compositor arrive. This CL modifies the condition to set the flag and sets it
only when the widget is layer backed.

BUG= 623950 

Review-Url: https://codereview.chromium.org/2343433005
Cr-Commit-Position: refs/heads/master@{#419702}

[modify] https://crrev.com/4a528effa127e1db82476eeb57c57649664af9b5/ui/views/cocoa/bridged_native_widget.mm

With this solution we have side effect: browser's window is flashing during some navigations (e.g. when opening homepage with Cmd+Shift+H).

This happens because of code in ScopedBrowserShower class (in browser_navigator.cc). It invokes Show() method on browser's window and as a consequence of this it triggers newly added code in BridgedNativeWidget::SetVisibilityState(), because we don't check here that window is already visible.

Confirmed that this causes the flashing behavior. Thanks for tracking this down. Your reasoning also looks correct. Checking for window visibility before setting the alpha value to 0 fixes the flashing. Have filed  issue 654961 .