Chromebook has old copy of a window's contents "stuck" on the background |
||||||
Issue descriptionVersion: 49.0.2623.59 OS: ChromeOS What steps will reproduce the problem? No idea; I had switched the device to Tablet mode and then unlocked it, so that may be related? System has a single window with two tabs in it. What is the expected output? What do you see instead? When I un-maximized my window, and moved it around, there was another, older, copy of it underneath - it looked like another window was still open, but it turns out to be just stale on-screen imagery. Only seen this once, but I don't often use Tablet-mode, so it may still be a new regression.
,
Mar 1 2016
Interestingly, I have two user profiles signed-in, and this "stuck" window appears on both profiles.
,
Mar 3 2016
Sneakily assigning this to tapted@, since he grabbed 591535, and they seem likely related!
,
Mar 3 2016
Oh weird. I don't think they're related - the stuff I regressed in Issue 591535 was pretty specific to tab loading spinners. There is some pretty crazy stuff that happens when you [un]maximize a window on CrOS though. Cleaning up the layers involved is the responsibility of the ash::CrossFadeObserver - https://code.google.com/p/chromium/codesearch#chromium/src/ash/wm/window_animations.cc&q=CrossFadeObserver&sq=package:chromium&l=265 I encountered it around the m49 timeframe in https://codereview.chromium.org/1474993003/ but I'm preeeetty sure that only fixed a bug. I think oshima is the expert here and will have a much better clue than me what this might be.
,
Mar 5 2016
FWIW I just signed-in to ChromeOS 49.0.2623.75 w/ my corp account, then signed-in a second account, and I now have the window from my corp account appearing on _both_ accounts' workspaces - the other account's windows only appear on one. Bumping priority since this seems a more fundamental regression.
,
Mar 15 2016
,
Mar 15 2016
I think the issue #5 is different issue. wez@, can you file a separate bug with more detailed description and log file?
,
Mar 16 2016
Re #7: If I'm able to repro the weird window behaviour again then I will do, yes!
,
Mar 16 2016
Just wanted to confirm. Is this window that appeared on both accounts are functional on both desktop?
,
Mar 16 2016
This bug is about a window that was non-functional (and had no corresponding processes listed in Task Manager) - basically just a layer that was somehow "stuck" in the compositor tree.
,
Mar 17 2016
So am I correct that stale window image stuck on background even when you switched the desktop, which has different background image? If so, there is no need to file a separate bug.
,
Mar 17 2016
I'm sorry, I assumed that comment #9 was asking about this bug, rather than my comment #5 - in #5 the window appeared on both desktops and appeared to be interactive on both.
,
Mar 17 2016
,
Mar 17 2016
Sorry, I wasn't clear either. If #5 happened again, please file a separate bug. If this (#1) bug happened again, could you try changing the resolution using ctrl/shift/+- and see if that clears the image, or sticks?
,
Mar 18 2016
I couldn't reproduce this on ToT. I'll check if this is fixed in 50.
,
Mar 19 2016
I tested this on 50.0.2661.39 and could not reproduce the issue. I'll close this, but please reopen if you have this issue on m50 beta. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by w...@chromium.org
, Mar 1 201629.9 KB
29.9 KB View Download