GitLab

This change introduces a new method WidgetDelegate::WindowWillClose() to
allow WidgetDelegates to hook into the Widget lifecycle *after* the
decision that the widget will definitely close has been made but
*before* any internal state of the Widget has actually begun to destroy.
This change then has DialogDelegate use that new hook to implement the
close-callback behavior, rather than having the close callback come via
DialogClientView.

Before this change:
1. [user presses Accept on a dialog]
2. DialogClientView::ButtonPressed()
3. DialogClientView::AcceptWindow()
4. DialogDelegate::Accept() [returns true]
5. Widget::CloseWithReason()
6. NonClientView::CanClose()
7. DialogClientView::CanClose()
8. DialogDelegate::Close (!) [returns true]

After this change:
1. [user presses Accept on a dialog]
2. DialogClientView::ButtonPressed()
3. DialogDelegate::AcceptDialog()
4. DialogDelegate::Accept() [returns true]
5. Widget::CloseWithReason()
6. WidgetDelegate::WindowWillClose()

This returns ClientView::CanClose() to being a pure predicate, at least
for DialogDelegate, rather than a method that has side-effects. Other
subclasses of ClientView still have issues with mixed behavior in this
regard.

This also centralizes the logic for delivering Accept/Close/Cancel
callbacks inside DialogDelegate, which removes some complexity from
DialogClientView.

Bug: 1011446
Change-Id: I96519d6fa4c374de4f06de22c30c4ab5ac03d98e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2071037Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#746884}