Incorrect opacity for window on ChromeOS |
|||||
Issue descriptionWe've noticed this in the past but never been able to reproduce it. Now that the "Slow UI Animations" debug feature has landed it's much easier to reproduce. In the wild this would typically result in the window being almost transparent (e.g. alpha=0.01) and that looks a bit like the screen is broken. When slowing down animations, it's much easier to get a window stuck at alpha=~0.5. Seems like an animation is cancelled and opacity ends up wrong. The best way we've found to reproduce this is by enabling "Slow UI Animations" in about:flags and then try to close windows using the top-left close button at the same time as you hit Ctrl-N to open new windows. Screenshot of the bad state attached.
,
Jan 31 2017
Per triage: please take a look.
,
Jan 31 2017
I suspect James is right, that the window close animation isn't cleaning up correctly if aborted. Although I've no idea why the close animation would be aborted when a new window is created.
,
Jan 31 2017
I guess creating new window may push another window left/right, which may abort animation?
,
Feb 1 2017
Able to repo. I can repro by simply Ctrl+N and immediately click on the window's title bar. The opacity is stuck to its value at the time of the click. Will start looking into why.
,
Feb 1 2017
I would start with HidingWindowAnimationObserverBase. No doubt we're not handling the animation being aborted correctly.
,
Feb 1 2017
@reveman, can you please tell me how exactly I can repro the behavior you mentioned in the bug description? I can only repro the case I mentioned in #5. For that case, the suggested fix is: https://codereview.chromium.org/2666413002 We used to apply the initial opacity rather than the initial target opacity. However, I'm not sure that this is the same issue you described.
,
Feb 2 2017
That might be enough to fix my issue. I'm not sure exactly where I clicked. I'll test your patch asap to see if I can still reproduce the problem.
,
Feb 2 2017
Yes, please let me know. I will send the CL for review since we need that fix anyway.
,
Feb 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1b08650cd63cbd6fa11cc5a840d716a3b945306b commit 1b08650cd63cbd6fa11cc5a840d716a3b945306b Author: afakhry <afakhry@chromium.org> Date: Mon Feb 06 19:36:26 2017 Fix opacity getting stuck when clicking on a new window while it's being created While the window is being created, it's going through an opacity animation. Clicking on the window's title bar at this point, starts a drag. We must store the target opacity (rather than the current one) to be able to set it on drag completion, otherwise the window opacity will be stuck to its value at the time of the click. BUG= 687003 Review-Url: https://codereview.chromium.org/2666413002 Cr-Commit-Position: refs/heads/master@{#448352} [modify] https://crrev.com/1b08650cd63cbd6fa11cc5a840d716a3b945306b/ash/common/wm/drag_details.cc
,
Apr 5 2017
,
May 8 2017
Chrome OS 9532.0.0, 60.0.3092.0 |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by jamescook@chromium.org
, Jan 31 2017Components: UI>Shell>WindowManager