Mac: Convince the WindowServer to update the print preview shadow on retina screens

Mac: Convince the WindowServer to update the print preview shadow on retina screens

The OSX WindowServer currently forgets to draw the window shadow on
print preview when it's shown on retina displays. This started flakily
in 10.10 and now always happens. It's probably something to do with the
print preview dialog being wholly a layer-hosting NSView with the
WebContents showing print preview WebUI. This, combined with the private
APIs we currently use to show the dialog, seems to confuse the shadow
generation code in the WindowServer.

To fix, it seems we can make a call to -[NSWindow setFrame:] once the
animation completes. Other ways of invalidating the shadow didn't have
an effect. The setFrame call can't be a no-op, but it can be immediately
reversed. This doesn't seem to negatively impact other dialogs.

It does mean the dialog still doesn't have a shadow whilst it is
animating in, but that's less noticeable.

BUG=436884
TEST=Show Print Preview (Cmd+p) on a retina screen. It should have a
border/shadow.

Committed: https://crrev.com/21610ba731345e89dcb62229b3eceac977f6425b
Cr-Commit-Position: refs/heads/master@{#392286}

[tapted, 2016-05-09 03:47:03]

Description was changed from

==========
Mac: Convince the WindowServer to update the print preview shadow on retina
screens



BUG=436884
==========

to

==========
Mac: Convince the WindowServer to update the print preview shadow on retina
screens

The OSX WindowServer currently forgets to draw the window shadow on
print preview when it's shown on retina displays. This started flakily
in 10.10 and now always happens. It's probably something to do with the
print preview dialog being wholly a layer-hosting NSView with the
WebContents showing print preview WebUI. This, combined with the private
APIs we currently use to show the dialog, seems to confuse the shadow
generation code in the WindowServer.

To fix, it seems we can make a call to -[NSWindow setFrame:] once the
animation completes. Other ways of invalidating the shadow didn't have
an effect. The setFrame call can't be a no-op, but it can be immediately
reversed. This doesn't seem to negatively impact other dialogs.

It does mean the dialog still doesn't have a shadow whilst it is
animating in, but that's less noticeable.

BUG=436884
TEST=Show Print Preview (Cmd+p) on a retina screen. It should have a
border/shadow.
==========

[tapted, 2016-05-09 03:47:03]

tapted@chromium.org changed reviewers:
+ erikchen@chromium.org

[erikchen, 2016-05-09 05:29:07]

lgtm, though not super happy about this.

https://codereview.chromium.org/1956283002/diff/1/ui/base/cocoa/constrained_w...
File ui/base/cocoa/constrained_window/constrained_window_animation.mm (right):

https://codereview.chromium.org/1956283002/diff/1/ui/base/cocoa/constrained_w...
ui/base/cocoa/constrained_window/constrained_window_animation.mm:235: [window_
setFrame:frame display:NO animate:NO];
uh. okay. I guess. In general I prefer moving away from private APIs, especially
when they cause problems.

[tapted, 2016-05-09 05:35:56]

Thanks Erik!

https://codereview.chromium.org/1956283002/diff/1/ui/base/cocoa/constrained_w...
File ui/base/cocoa/constrained_window/constrained_window_animation.mm (right):

https://codereview.chromium.org/1956283002/diff/1/ui/base/cocoa/constrained_w...
ui/base/cocoa/constrained_window/constrained_window_animation.mm:235: [window_
setFrame:frame display:NO animate:NO];
On 2016/05/09 05:29:06, erikchen wrote:
> uh. okay. I guess. In general I prefer moving away from private APIs,
especially
> when they cause problems.

I hear ya :). I think to resolve this we'd need to either drastically change or
remove the animations, and/or draw the shadow ourselves (maybe by extending the
size of the window slightly and giving the WebContents a parent layer).

Even using the "supported" animations from -[NSWindow animationBehaviour] might
not cope with the layer stuff.

[tapted, 2016-05-09 05:36:45]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2016-05-09 05:36:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1956283002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1956283002/1

[commit-bot: I haz the power, 2016-05-09 05:41:01]

Description was changed from

==========
Mac: Convince the WindowServer to update the print preview shadow on retina
screens

The OSX WindowServer currently forgets to draw the window shadow on
print preview when it's shown on retina displays. This started flakily
in 10.10 and now always happens. It's probably something to do with the
print preview dialog being wholly a layer-hosting NSView with the
WebContents showing print preview WebUI. This, combined with the private
APIs we currently use to show the dialog, seems to confuse the shadow
generation code in the WindowServer.

To fix, it seems we can make a call to -[NSWindow setFrame:] once the
animation completes. Other ways of invalidating the shadow didn't have
an effect. The setFrame call can't be a no-op, but it can be immediately
reversed. This doesn't seem to negatively impact other dialogs.

It does mean the dialog still doesn't have a shadow whilst it is
animating in, but that's less noticeable.

BUG=436884
TEST=Show Print Preview (Cmd+p) on a retina screen. It should have a
border/shadow.
==========

to

==========
Mac: Convince the WindowServer to update the print preview shadow on retina
screens

The OSX WindowServer currently forgets to draw the window shadow on
print preview when it's shown on retina displays. This started flakily
in 10.10 and now always happens. It's probably something to do with the
print preview dialog being wholly a layer-hosting NSView with the
WebContents showing print preview WebUI. This, combined with the private
APIs we currently use to show the dialog, seems to confuse the shadow
generation code in the WindowServer.

To fix, it seems we can make a call to -[NSWindow setFrame:] once the
animation completes. Other ways of invalidating the shadow didn't have
an effect. The setFrame call can't be a no-op, but it can be immediately
reversed. This doesn't seem to negatively impact other dialogs.

It does mean the dialog still doesn't have a shadow whilst it is
animating in, but that's less noticeable.

BUG=436884
TEST=Show Print Preview (Cmd+p) on a retina screen. It should have a
border/shadow.
==========

[commit-bot: I haz the power, 2016-05-09 05:41:02]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-09 05:42:02]

Description was changed from

==========
Mac: Convince the WindowServer to update the print preview shadow on retina
screens

The OSX WindowServer currently forgets to draw the window shadow on
print preview when it's shown on retina displays. This started flakily
in 10.10 and now always happens. It's probably something to do with the
print preview dialog being wholly a layer-hosting NSView with the
WebContents showing print preview WebUI. This, combined with the private
APIs we currently use to show the dialog, seems to confuse the shadow
generation code in the WindowServer.

To fix, it seems we can make a call to -[NSWindow setFrame:] once the
animation completes. Other ways of invalidating the shadow didn't have
an effect. The setFrame call can't be a no-op, but it can be immediately
reversed. This doesn't seem to negatively impact other dialogs.

It does mean the dialog still doesn't have a shadow whilst it is
animating in, but that's less noticeable.

BUG=436884
TEST=Show Print Preview (Cmd+p) on a retina screen. It should have a
border/shadow.
==========

to

==========
Mac: Convince the WindowServer to update the print preview shadow on retina
screens

The OSX WindowServer currently forgets to draw the window shadow on
print preview when it's shown on retina displays. This started flakily
in 10.10 and now always happens. It's probably something to do with the
print preview dialog being wholly a layer-hosting NSView with the
WebContents showing print preview WebUI. This, combined with the private
APIs we currently use to show the dialog, seems to confuse the shadow
generation code in the WindowServer.

To fix, it seems we can make a call to -[NSWindow setFrame:] once the
animation completes. Other ways of invalidating the shadow didn't have
an effect. The setFrame call can't be a no-op, but it can be immediately
reversed. This doesn't seem to negatively impact other dialogs.

It does mean the dialog still doesn't have a shadow whilst it is
animating in, but that's less noticeable.

BUG=436884
TEST=Show Print Preview (Cmd+p) on a retina screen. It should have a
border/shadow.

Committed: https://crrev.com/21610ba731345e89dcb62229b3eceac977f6425b
Cr-Commit-Position: refs/heads/master@{#392286}
==========

[commit-bot: I haz the power, 2016-05-09 05:42:02]

Patchset 1 (id:??) landed as
https://crrev.com/21610ba731345e89dcb62229b3eceac977f6425b
Cr-Commit-Position: refs/heads/master@{#392286}