Mac: Fix window ordering for certificate viewer/selector sheets and overlays.

components/constrained_window/native_web_contents_modal_dialog_manager_views_mac.mm

 // Copyright 2016 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.
 
 #include "components/constrained_window/native_web_contents_modal_dialog_manager_views_mac.h"
 
 #import <Cocoa/Cocoa.h>
 
 #include "components/constrained_window/constrained_window_views.h"
 #include "components/guest_view/browser/guest_view_base.h"
 #include "components/web_modal/web_contents_modal_dialog_manager.h"
 #include "content/public/browser/web_contents.h"
 #import "ui/gfx/mac/coordinate_conversion.h"
 #include "ui/views/widget/widget.h"
 #include "ui/views/widget/widget_delegate.h"
 
 using web_modal::WebContentsModalDialogManager;
 using web_modal::SingleWebContentsDialogManager;
 
 namespace {
 
 // Sets visibility and mouse events for a Cocoa NSWindow* and an attached sheet.
 void SetSheetVisible(gfx::NativeWindow overlay, bool visible) {
-  CGFloat alpha = visible ? 1.0 : 0.0;
   BOOL ignore_events = visible ? NO : YES;
 
   // Don't allow interaction with the tab underneath the overlay.
   [overlay setIgnoresMouseEvents:ignore_events];
 
-  [[overlay attachedSheet] setAlphaValue:alpha];
+  [[overlay attachedSheet] setAlphaValue:visible ? 1.0 : 0.0];
   [[overlay attachedSheet] setIgnoresMouseEvents:ignore_events];
+
+  // Make sure overlay layers for hidden Cocoa dialogs are always behind
+  // overlays which are in use. If they are not hidden, the attached sheet needs
+  // to be in front of its corresponding overlay window to accept mouse clicks.
+  [overlay setLevel:visible ? NSFloatingWindowLevel : NSNormalWindowLevel];

[tapted, 2016/12/11 23:28:20]

I think NSFloatingWindowLevel would mean that dragging another window over the
overlay would cause the overlay window to remain floating above it. (maybe
sheets and parent/child relationships alter this behaviour, but that's normally
what setLevel is for, so I don't think we want it here).

I have a theory about what's happening. When there are two overlay windows
attached, AppKit has multiple childWindows to keep "on top" of the browser
window. But it might be using the order that they were added to childWindows to
decide how they should be ordered amongst themselves.

When showing, can you try something like

NSWindow* parent = [overlay parentWindow];
[parent removeChildWindow:parent];
[parent addChildWindow:overlay];

That might insert the window at the end, to ensure AppKit always puts the most
recently shown one on top.

[Patti Lor, 2016/12/12 01:29:04]

That works! Have done this for all three cases. All of them also required the
sheet to be reparented as well.

+  [[overlay attachedSheet]
+      setLevel:visible ? NSStatusWindowLevel : NSNormalWindowLevel];
 }
 
 }  // namespace
 
 namespace constrained_window {
 
 NativeWebContentsModalDialogManagerViewsMac::
     NativeWebContentsModalDialogManagerViewsMac(
         gfx::NativeWindow dialog,
         web_modal::SingleWebContentsDialogManagerDelegate* native_delegate)
@@ skipping 47 matching lines @@
 void NativeWebContentsModalDialogManagerViewsMac::HideWidget(
     views::Widget* widget) {
   NSWindow* dialog_window = widget->GetNativeWindow();
   // Avoid views::Widget::Hide(), as a call to orderOut: on a NSWindow with an
   // attached sheet will close the sheet. Instead, just set the sheet to 0
   // opacity and don't accept click events.
   SetSheetVisible(dialog_window, false);
 }
 
 }  // namespace constrained_window