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

components/constrained_window/native_web_contents_modal_dialog_manager_views_mac.mm

Index: components/constrained_window/native_web_contents_modal_dialog_manager_views_mac.mm
diff --git a/components/constrained_window/native_web_contents_modal_dialog_manager_views_mac.mm b/components/constrained_window/native_web_contents_modal_dialog_manager_views_mac.mm
index 5df747e7ecef4bb8ac1c193e4cdd0835d64b641e..d12780c5d54783a5ea165666dffd0a333a0b9272 100644
--- a/components/constrained_window/native_web_contents_modal_dialog_manager_views_mac.mm
+++ b/components/constrained_window/native_web_contents_modal_dialog_manager_views_mac.mm
@@ -21,14 +21,20 @@ 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