tapted - I think this is a mac views thing. Wanna take it?

Yeah - this has been around for a while. I think it's an Apple bug, which we'll need to workaround. However, we might be able to reuse parts of the workaround that Karan did for the bubble dialog shadows.

Instead of a bubble, this one is a window-modal sheet. The shadow is generated by the OSX Window Server from the CALayer. For some reason it doesn't get clipped properly when the window modal sheet slides back into the toolbar.

I think options are:
 A) Make the *views* dialog background transparent, but give the NSWindow a solid background that's drawn by Quartz and is the correct color (which I think it already has, even)
   * doing this, ensure we don't lose subpixel AA
 B) Somehow otherwise convince the window server it shouldn't try to make shadows from the CALayer
 C) Use an animation of our own that doesn't have the glitch, or that we can call [NSWindow invalidateShadow] between frames
   * this requires moving away from the modal sheet APIs
 D) Somehow clip the shadow on the Window server (I have no idea how this could be done..)

We should also see what happens on 10.9 - it probably doesn't have the bug at all, because "B" is already in effect -- only since 10.10 does OSX try to make shadows from CALayers

Ooh - the other thing to explore for these sheets is whether we want to switch out the NSView hosting the CALayer with an NSVisualEffectView. Drawing the views UI with a transparent background will let the OSX 10.10 visual effects happen, which makes colors from content behind the window bleed through.

There's also a `maskImage` property, but we might not need it.

migrating Phase2 stuff to M53

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Could it be..... did Apple fix this in 10.11.6 \o/. I can no longer reproduce :o

10.11.6 came a few days ago on July 18.

Anyone still got 10.11.5 lying around who can verify this still repros there?

I can't repro under 10.11.6 in 53.0.2785.21 dev or m54 Canary, but I don't think we did anything to address this.

Maybe some of other shadow bugs are resolved too....

Verified this is not due to 10.11.6. 

Running a bisect gives the following changelog url - https://chromium.googlesource.com/chromium/src/+log/b9debcdd14086d59327dcb0cfd2044b41c998ae8..ef5b4a2339a11c17bd4632e0606d851f6698476f

Hence seems this was fixed by http://crrev.com/2069103004. 

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

commit 9464d37d42d7b7895421a05bd3f0b5f0a3eb3266
Author: tapted <tapted@chromium.org>
Date: Tue Nov 29 04:02:54 2016

MacViews: Protect against orderOut: on an NSWindow with an attached sheet.

This fixes and re-enables NativeWidgetMacTest.WindowModalSheet with some
additional test expectations. It was reverted in r433028 when it started
failing.

Fundamentally, the problem is that calling orderOut: on an NSWindow with
an attached sheet results in utterly broken behavior in AppKit,
documented in http://crbug.com/667602.

AppKit's broken behaviour with orderOut and regular child windows is
already handled by BridgedNativeWidget by recreating the parent/child
relationships. However, it can't do this for sheets. It's not possible
to "reattach" a sheet once it becomes detached. And even giving a sheet
a parentWindow results in graphical glitches ( http://crbug.com/605098 ).
Sheets use -[NSWindow sheetParent], not -[NSWindow parentWindow].

Note that -[NSApp hide:] works. It's just -[NSWindow orderOut:] that's
broken. But we need the triggers from -[NSApp hide:] to be consistent
with the different things that need to happen for sheets.

Add checks to BridgedNativeWidget to detect attempts to orderOut: a
window with an attached sheet. Different solutions need to be sought for
these, such as what Chrome already does for the certificate viewer sheet
when we make it tab-modal.

Update DCHECKs in WidgetOwnerNSWindowAdapter to properly support sheets.
This allows NativeWidgetMacTest.WindowModalSheet to be re-enabled.

Updates BridgedNativeWidget::OnVisibilityChanged() to properly fix
 http://crbug.com/605098 . This bug still manifests in Chrome, but only
after a call to [NSApp hide:]. Re-showing a window improperly attaches
the parent as a parentWindow (rather than only sheetParent), and this is
the cause of the graphical glitches.

BUG= 666503 ,  605098 , 667602

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

[modify] https://crrev.com/9464d37d42d7b7895421a05bd3f0b5f0a3eb3266/ui/views/cocoa/bridged_native_widget.mm
[modify] https://crrev.com/9464d37d42d7b7895421a05bd3f0b5f0a3eb3266/ui/views/cocoa/widget_owner_nswindow_adapter.mm
[modify] https://crrev.com/9464d37d42d7b7895421a05bd3f0b5f0a3eb3266/ui/views/widget/native_widget_mac_unittest.mm