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

ui/views/cocoa/bridged_native_widget.mm

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #import "ui/views/cocoa/bridged_native_widget.h"
 
 #import <objc/runtime.h>
 #include <stddef.h>
 #include <stdint.h>
 
@@ skipping 560 matching lines @@
     return;
   }
 
   // Non-modal windows are not animated. Hence opaque non-modal windows can
   // appear with a "flash" if they are made visible before the frame from the
   // compositor arrives. To get around this, set the alpha value of the window
   // to 0, till we receive the correct frame from the compositor. Also, ignore
   // mouse clicks till then.
   // TODO(karandeepb): Investigate whether similar technique is needed for other
   // dialog types.
-  if ([window_ isOpaque] && !native_widget_mac_->GetWidget()->IsModal()) {
+  if (layer() && [window_ isOpaque] &&

[tapted, 2016/09/19 07:35:34]

This reminds me a bit of https://codereview.chromium.org/2061693003/ - still a
WIP - but it would alter the states under which layer() is null. (e.g. we could
DCHECK(layer()) here, and return early before this point in the function if
bridged_view_ is ever null.)

One thing to consider: with Widget::InitParams::TYPE_CONTROL, altering this line
changes behaviour. BNW::Init() calls SetVisibilityState before
NWM::InitNativeWidget calls CreateLayer(). So, what should TYPE_CONTROL do wrt
the "flash"?

I think either
 - all TYPE_CONTROL will be transparent anyway, or
 - TYPE_CONTROL isn't used [yet] on Mac -- it was once used for the app list,
but that's no more.

Might need some investigation.

[karandeepb, 2016/09/20 08:04:51]

NativeWidgetAura initializes the layer before showing the window for
TYPE_CONTROL widgets -
https://cs.chromium.org/chromium/src/ui/views/widget/native_widget_aura.cc?dr....
So we seem to be diverging from its behavior. 
Yeah from what I see on codesearch, most of the TYPE_CONTROL widgets are
transparent. Don't think (Not sure) there are any behind one of the MacViews
flags. An example for MacViewsBrowser is the Find In Page popup. I guess we can
defer taking a look at this, till we get an actual bug.

+      !native_widget_mac_->GetWidget()->IsModal()) {
     initial_visibility_suppressed_ = true;
     [window_ setAlphaValue:0.0];
     [window_ setIgnoresMouseEvents:YES];
   }
 
   if (new_state == SHOW_AND_ACTIVATE_WINDOW) {
     [window_ makeKeyAndOrderFront:nil];
     [NSApp activateIgnoringOtherApps:YES];
   } else {
     // ui::SHOW_STATE_INACTIVE is typically used to avoid stealing focus from a
@@ skipping 792 matching lines @@
   [bridged_view_ setMouseDownCanMoveWindow:draggable];
   // AppKit will not update its cache of mouseDownCanMoveWindow unless something
   // changes. Previously we tried adding an NSView and removing it, but for some
   // reason it required reposting the mouse-down event, and didn't always work.
   // Calling the below seems to be an effective solution.
   [window_ setMovableByWindowBackground:NO];
   [window_ setMovableByWindowBackground:YES];
 }
 
 }  // namespace views