Flash of white seen when closing MacViews task manager window |
|||||||||||||
Issue descriptionVersion: 55.0.2868.0 OS: macOS 10.11.6 What steps will reproduce the problem? (1) --enable-features=MacViewsNativeDialogs,MacViewsWebUIDialogs (2) Open the task manager (3) Close the task manager window (4) See white flash when closing the window What is the expected output? No flash of white when closing the window. What do you see instead? A flash of white when the window is being closed. Seems related to issue 623950 . Please use labels and text to provide additional information.
,
Oct 21 2016
Like the issue 645343 which https://codereview.chromium.org/2312133002/ fixed, there's also a corresponding black strip displayed for a MacViewsBrowser when it's closed, which has the same root cause as this issue. Further, when widgets are closed using Widget::CloseNow, we don't orderOut, and that also causes the window to not close "gracefully". Will post screenshots. Think this happens since we destroy the compositor during [window close]. Some initial thoughts regarding ways to solve this- 1) Simply doing a [window_ orderOut] in BridgedNativeWidget::OnWindowWillClose should fix this. 2) Another thought -> What if we override NativeWidgetMacNSWindow's close method, and use a windowDidClose method so that we destroy the BNW and the NWM "after" [window_ close]. Knowing that the window has already been closed may also help in simplifying out teardown paths for BNW. It'll also keep everything "alive" during [window_ close]. Haven't looked into how aura widgets and RWHVM handle these things.
,
Dec 12 2016
,
Feb 1 2017
Before I unassign myself, IIRC option no. 1 in c#2 wasn't correct, since orderOut can be async. We probably need to retain the compositor during [window close] like it's done in the renderer. See the comments in https://codereview.chromium.org/2454283002/.
,
Feb 1 2017
,
Feb 2 2017
Making the contentView layer-backed seemed to have some effect on this when I played around. See sdy's https://codereview.chromium.org/2622083007/ Note there also seemed to be a difference whether Cmd+w was used to close the window versus the close button.
,
Apr 12 2017
,
Oct 12 2017
Seems like this can be moved out of macViews Harmony and into the macViewsBrowser phase (it shows in the list of bug using the macViews Harmony link you gave me)?
,
Oct 12 2017
Yep, that is correct. Moved.
,
Mar 26 2018
sdy@, can you take a look at this for M-69?
,
Mar 26 2018
Please note that the MacViews Task Manager needs a *lot* of work to not feel like an ugly, janky, hacky thing that should never be found running on a Mac (I could probably file as many bugs on this bit of UI as I've already filed on the MacView top chrome). I don't think there's any urgency in converting the Task Manager to Views (I actually don't think there's any reason to convert it). I hope that the Task Manager doesn't get mixed into the rush to ship MacViews browser.
,
Mar 27 2018
,
Jul 10
,
Jul 12
,
Nov 23
**Mass UI Triage** We were unable to reproduce this bug on the latest canary 72.0.3618.0 on Mac OS 10.13.6. If this bug still reproduces for you, please reopen or file a new issue. Thanks! |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by karandeepb@chromium.org
, Sep 23 2016Status: Assigned (was: Untriaged)