views: simplify DialogDelegate close path
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}
Showing
Please register or sign in to comment