diff options
author | tapted <tapted@chromium.org> | 2014-11-24 14:59:11 -0800 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2014-11-24 23:00:38 +0000 |
commit | bae441200c5f14bf67eb817e628924a0a846cdd1 (patch) | |
tree | 5a6271a2443d51cb9f96d64808dc8b3ca876662f /sync/util | |
parent | 90590193a9c5b5bc674f1c7680761306ed42c1f1 (diff) | |
download | chromium_src-bae441200c5f14bf67eb817e628924a0a846cdd1.zip chromium_src-bae441200c5f14bf67eb817e628924a0a846cdd1.tar.gz chromium_src-bae441200c5f14bf67eb817e628924a0a846cdd1.tar.bz2 |
MacViews: Phase out -[NSWindow childWindows], implement our own
The way NSWindow implements child windows has a few deal-breakers:
- There is no way to have a child window that is initially hidden,
- Hiding (orderOut:) a child and showing it again breaks the
auto-positioning, and
- Adding a child to a hidden parent shows the parent.
This change re-implements child windows with a vector in
BridgedNativeWidget, maintaining the trend of BridgedNativeWidget
performing tasks similar to aura::Window (i.e. it is where aura
houses its child windows).
Parent NSWindows that are not NativeWidgetMac are disallowed in this
change, to ensure lifetime of the child windows is consistent.
With this, we can finally implement NativeWidgetMac::Hide, and get
child-window visibility working (coming in a follow-up with more tests).
Of course, we lose the nice bits of [NSWindow childWindows]: the origin
and z-order of child windows is no longer kept in sync with the parent.
But it was broken anyway. If it's needed, it will be implemented in a
follow-up.
BUG=378134
TEST=Covered by the existing WidgetTests for lifetime and child windows.
views_unittests unchanged: 469* tests run. 23 fail. 16 crash.
*up from 458 the last time I mentioned it on this bug.
Review URL: https://codereview.chromium.org/731053002
Cr-Commit-Position: refs/heads/master@{#305512}
Diffstat (limited to 'sync/util')
0 files changed, 0 insertions, 0 deletions