add HideAndClose in preference to having Close sometimes magically defer

add HideAndClose in preference to having Close sometimes magically defer

DCHECK in linked bug was caused by Widget::CloseAllSecondaryWidgets()
calling Close() but the Close getting deferred due to being an animated
hide, which caused the eventual WM_NCDESTROY to be delayed, which led to
cleaning up GPU resources too late.

So, instead of magically converting closes into hide-and-then-close,
add a new method that explicitly does that, so that the previous
behaviour of Close() is preserved.

And, update a couple obvious places where the HideAndClose is desirable.
There will probably be more places where it will need to be adjusted
but not changing them is a minor cosmetic problem, rather than a somewhat
complicated lifetime change.

R=sky@chromium.org
BUG=226716

[sky, 2013-04-05 16:20:32]

This would make Widget::Close() behave differently on chromeos and
win/linux-aura. It would also means folks have to know ahead of time whether
they might want a hide animation or not.

Seems like the core issue is that we may shut down while an animation is
happening. I don't see how this fixes that. Should we instead be tracking list
of open HWNDs that are animating and destroy them if we hit shutdown?

[scottmg, 2013-04-05 19:21:01]

On 2013/04/05 16:20:32, sky wrote:
> This would make Widget::Close() behave differently on chromeos and
> win/linux-aura. It would also means folks have to know ahead of time whether
> they might want a hide animation or not.
> 
> Seems like the core issue is that we may shut down while an animation is
> happening. I don't see how this fixes that. Should we instead be tracking list
> of open HWNDs that are animating and destroy them if we hit shutdown?

Enumerating all windows and closing is basically what's already happening during
shutdown here:

https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/widget/na...

called from 

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/lif...

But that calls Close() which doesn't work because that instead triggers the
animation start. Maybe Close() should be able to tell that shutdown is in
progress? (CloseNow looks like it would miss some important shutdown behaviour)

[sky, 2013-04-05 19:57:51]

Presumably when we hit this we're about to shutdown. I suggest CloseNow and
if that doesn't work then a CloseDontAnimate that is only invoked from
views<https://code.google.com/p/chromium/codesearch#chromium/src/ash/shell.h&cl=GROK&l=54&ct=xref_jump_to_def>
::Widget<https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/widget/widget.h&cl=GROK&l=95&ct=xref_jump_to_def>
::CloseAllSecondaryWidgets<https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/widget/native_widget_aura.cc&cl=GROK&l=914&ct=xref_jump_to_def>
.


On Fri, Apr 5, 2013 at 12:21 PM, <scottmg@chromium.org> wrote:

> On 2013/04/05 16:20:32, sky wrote:
>
>> This would make Widget::Close() behave differently on chromeos and
>> win/linux-aura. It would also means folks have to know ahead of time
>> whether
>> they might want a hide animation or not.
>>
>
>  Seems like the core issue is that we may shut down while an animation is
>> happening. I don't see how this fixes that. Should we instead be tracking
>> list
>> of open HWNDs that are animating and destroy them if we hit shutdown?
>>
>
> Enumerating all windows and closing is basically what's already happening
> during
> shutdown here:
>
> https://code.google.com/p/**chromium/codesearch#chromium/**
> src/ui/views/widget/native_**widget_aura.cc&q=**
>
CloseAllSecondaryWidgets&sq=**package:chromium&type=cs&l=914<https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/widget/native_widget_aura.cc&q=CloseAllSecondaryWidgets&sq=package:chromium&type=cs&l=914>
>
> called from
>
> https://code.google.com/p/**chromium/codesearch#chromium/**
> src/chrome/browser/lifetime/**application_lifetime_aura.cc&**
>
q=HandleAppExitingForPlatform&**sq=package:chromium&type=cs&l=**41<https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/lifetime/application_lifetime_aura.cc&q=HandleAppExitingForPlatform&sq=package:chromium&type=cs&l=41>
>
> But that calls Close() which doesn't work because that instead triggers the
> animation start. Maybe Close() should be able to tell that shutdown is in
> progress? (CloseNow looks like it would miss some important shutdown
> behaviour)
>
>
https://codereview.chromium.**org/13699002/<https://codereview.chromium.org/1...
>

[scottmg, 2013-04-05 19:58:44]

OK, thanks. I'll close this CL then and post another that does that.

On Fri, Apr 5, 2013 at 12:57 PM, Scott Violet <sky@chromium.org> wrote:
> Presumably when we hit this we're about to shutdown. I suggest CloseNow and
> if that doesn't work then a CloseDontAnimate that is only invoked from
> views::Widget::CloseAllSecondaryWidgets.
>
>
> On Fri, Apr 5, 2013 at 12:21 PM, <scottmg@chromium.org> wrote:
>>
>> On 2013/04/05 16:20:32, sky wrote:
>>>
>>> This would make Widget::Close() behave differently on chromeos and
>>> win/linux-aura. It would also means folks have to know ahead of time
>>> whether
>>> they might want a hide animation or not.
>>
>>
>>> Seems like the core issue is that we may shut down while an animation is
>>> happening. I don't see how this fixes that. Should we instead be tracking
>>> list
>>> of open HWNDs that are animating and destroy them if we hit shutdown?
>>
>>
>> Enumerating all windows and closing is basically what's already happening
>> during
>> shutdown here:
>>
>>
>>
https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/widget/na...
>>
>> called from
>>
>>
>>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/lif...
>>
>> But that calls Close() which doesn't work because that instead triggers
>> the
>> animation start. Maybe Close() should be able to tell that shutdown is in
>> progress? (CloseNow looks like it would miss some important shutdown
>> behaviour)
>>
>> https://codereview.chromium.org/13699002/
>
>