Issue metadata
Sign in to add a comment
|
Window(s) incorrectly remain visible when switching users. |
||||||||||||||||||||||
Issue descriptionChrome Version: 62.0.3202.55 OS: Chrome Platform (v2) apps in my secondary profile do not create a shelf icon when launched, and do not hide when I switch back to my primary profile (via "Ctrl+Alt+." or the system tray) even if it's not in focus. In fact, the app from my secondary profile actually *gains* focus when I switch to my primary profile; even if I re-focus a browser window on my primary profile, switching back and forth will cause the rogue secondary-profile app window to come to the foreground and capture focus. When in the primary profile, the open app from my secondary profile (which should have hidden) does not create a shelf icon in the primary profile either. This includes built-in apps like Calculator and Text. This does not repro for normal extension windows or legacy/v1 "packaged" apps, nor for websites I've chosen to "Open in window"; those appear in the shelf for their desktop and do not automatically move to the primary desktop. Note: the missing app icon does not appear in the primary user's shelf, either. I've got a bunch of feedback reports filed under my username @ google.com -- having trouble because Chrome is very crashy right now, most recently crashing when I tried switching between profiles in multi-profile mode. I'll see if I can track down that particular crash.
,
Nov 6 2017
This does not repro for me in 63.0.3239.26 (Official Build) beta There's some weird shelf behavior: * No running "dot" when I launch Calculator or Text * Shelf icons slide around a lot on user switch But I do see the app icon, the windows do hide, and I don't have focus problems. msw/estade - maybe some regression fix that didn't get backported?
,
Nov 8 2017
I can't reproduce in 62 beta. assigning to msw to triage.
,
Nov 8 2017
I can't repro on ToT at #514627, I'll have to try 62 Beta on a device tomorrow. I tried: 1) Sign in to User1, "Sign in another user" (User2), launch calculator -> Shelf item shown. 2) Switch back to User1 -> Shelf item and window hidden, existing User1 chrome window active. Am I following your repro steps correctly? Do these issues repro for you on ToT, or just 62? Maybe try about:flags "Disable shelf model synchronization" / --ash-disable-shelf-model-synchronization?
,
Nov 8 2017
I saw a jump in occurrences of this on my GUADO with 2 monitors connected and after upgrading to 63 beta. It seems like the active window (be it browser or app) jumps to the newly selected profile.
,
Nov 8 2017
Several other Googlers have mentioned this occurring. One (CC'd) just updated to M63 and suggested this was happening with browser windows. #4: I believe those are the correct repro steps. But I'm not seeing it now after restarting for the update to 62.0.3202.74.
,
Nov 8 2017
,
Nov 8 2017
Re #4, *enabling* the shelf model synchronization made the issue disappear (it was 100% reproducable with it disabled).
,
Nov 8 2017
Thanks jmeurin@, I'll likely disable the feature for M63 and try to fix this for M-64. Can you check my repro steps above and let me know if there's anything I'm missing that would help me repro? (any particular focus/activation, pinned items, missing interactions, etc.). If you can list specific repro steps after a device restart that'd be very helpful, thanks.
,
Nov 9 2017
jmeurin: Just to be very clear, since I still haven't been able to repro, in #8, you clicked "Enable" for the "Disable shelf model synchronization" entry in about:flags, and that resolved your issue, correct? (sorry it's confusing but shelf model sync is on-by-default and 'enabling the flag' == 'disabling the feature')
,
Nov 9 2017
jmeurin@ what version are you running and what device are you using? jayhlee@, can you list your repro steps, and does enabling the shelf flag fix this? I would really appreciate more info from folks able to repro, thanks!
,
Nov 9 2017
I'm using a Samus running 64.0.3261.0 See the screenshot for the option. Steps to repro: - Boot - Logging to @google account - Bottom right menu -> Sign in another user - Sign in with @gmail account - Open a window in @google.com account - Switch (with the keyboard shortcut) to @gmail.com --> The previous @google window is visible (and updated) in the @gmail account. The Hangout android app in "Transparent UI" seems pretty good from @gmail to @google, but with the shelf sync disabled, it happened with all windows.
,
Nov 9 2017
I can repro inconsistently on linux-desktop chromeos with 2 displays: 1) Run chrome --login-manager --ash-host-window-bounds=700x700,700+0-700x700 2) Sign in to one user and then sign in a second user. 3) Open Calculator and/or browser windows, drag the windows between displays. 4) Press Ctrl+Alt+. to switch between users. Expected: All windows from the previous user are hidden, only windows from current user are shown. Actual: The MRU window (eg. just dragged across displays) is sometimes also shown. Michael, I haven't seen shelf icon or focus/activation issues. Can you file separate bugs if you have reliable repros for those? I can also repro this issue with --ash-disable-shelf-model-synchronization, so I don't think that's at fault. I'll start looking for defects in MultiUserWindowManagerChromeOS, UserSwitchAnimatorChromeOS, or similar, and maybe start bisecting to find a recent culprit or CL that changed timing to exacerbate an older defect. This may also relate to recent changes in session management, window state tracking, etc. Any help from folks that know this code better or have touched it recently is appreciated (I'm probably not the best owner at this point, but will try to investigate).
,
Nov 9 2017
Thanks Mike. I'll dup the one on my plate to this since you are looking at it. The one I had contains a video. But I have not got a chance to take a close look.
,
Nov 9 2017
,
Nov 16 2017
Hey Daisy, please take over this bug; this old CL may not be at fault, but it's very related: https://codereview.chromium.org/1688343002 I added some logging statements with the attached patch. The windows fail to hide when MultiUserWindowManagerChromeOS::SetWindowVisibility early returns here: https://cs.chromium.org/chromium/src/chrome/browser/ui/ash/multi_user/multi_user_window_manager_chromeos.cc?l=574 I'm not sure why the windows already have hidden target visibility, nor why this issue seems to occur more frequently since M62. My second attached patch attempts to debug the window visibility mismatch, but I couldn't find what's going wrong there... The actual defect may be somewhere beyond this early return, but I'm hoping that you can take a closer look and reassign if needed, thanks!
,
Nov 17 2017
I noticed this too on M63 beta. FR here: https://listnr.corp.google.com/report/84667917268
,
Nov 21 2017
Today (for the first time), I'm seeing this on my Samus device. My primary (work) profile has a chrome window that continues to display when I switch (ctrl-alt-.) to my personal profile. I can't fully interact with window in my personal profile, though (scrollbar works, but giving input focus to this text field doesn't). I would include OS version numbers/etc if I could figure out how to find them (after wandering through settings and internal search results, I failed :()..aha...found chrome://version... Google Chrome 63.0.3239.50 (Official Build) beta (64-bit) Revision 0 Platform 10032.39.0 (Official Build) beta-channel samus Firmware Version Google_Samus.6300.174.0 Let me know if there's any info I can provide while this is happening. FYI...my usual workflow is to use the device at home either standalone or connected to an external monitor, then come into the office and connect it to the external monitor on my desk...occasionally using it standalone when I've got meetings. I think I told it to do an Update Restart yesterday (maybe?)
,
Nov 21 2017
And as part of my usual "close device, unplug to go to meeting, reopen in meeting, close device, get back to desk and plug in monitor, reopen" flow, it isn't happening any more. So, I've only seen it the one time and the window lived on my external monitor.
,
Nov 22 2017
I can repro this using steps in #14. Looking.
,
Nov 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c751780dd515bb4cfbda5d41f26a339a41846ee8 commit c751780dd515bb4cfbda5d41f26a339a41846ee8 Author: xdai <xdai@chromium.org> Date: Wed Nov 22 05:07:31 2017 Cros: fix the issue that window(s) show on incorrect user desktop. It's caused by a code refactoring. Bug: 781491 Change-Id: I7be6edf96e18b1e93e754ed1a4b1658999afdb29 Reviewed-on: https://chromium-review.googlesource.com/784128 Reviewed-by: Stefan Kuhne <skuhne@chromium.org> Commit-Queue: Xiaoqian Dai <xdai@chromium.org> Cr-Commit-Position: refs/heads/master@{#518538} [modify] https://crrev.com/c751780dd515bb4cfbda5d41f26a339a41846ee8/chrome/browser/ui/ash/multi_user/user_switch_animator_chromeos.cc
,
Nov 22 2017
The fix in #22 should have fixed the bug in comment#14. However, the offending CL that caused the bug in #14 was landed in M63 which could not explain the bug in the original report which was in M62. I guess it might be a different issue.
,
Nov 22 2017
,
Nov 22 2017
This bug requires manual review: We are only 12 days from stable. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 27 2017
,
Nov 28 2017
,
Nov 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d0ba549a42ac10f2de414e2a69d2a7d6e5e45aa7 commit d0ba549a42ac10f2de414e2a69d2a7d6e5e45aa7 Author: xdai <xdai@chromium.org> Date: Tue Nov 28 23:56:11 2017 [Merge to M63] Cros: fix the issue that window(s) show on incorrect user desktop. It's caused by a code refactoring. Bug: 781491 TBR=skuhne@chromium.org (cherry picked from commit c751780dd515bb4cfbda5d41f26a339a41846ee8) Change-Id: I7be6edf96e18b1e93e754ed1a4b1658999afdb29 Reviewed-on: https://chromium-review.googlesource.com/784128 Reviewed-by: Stefan Kuhne <skuhne@chromium.org> Commit-Queue: Xiaoqian Dai <xdai@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#518538} Reviewed-on: https://chromium-review.googlesource.com/795031 Reviewed-by: Xiaoqian Dai <xdai@chromium.org> Cr-Commit-Position: refs/branch-heads/3239@{#594} Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} [modify] https://crrev.com/d0ba549a42ac10f2de414e2a69d2a7d6e5e45aa7/chrome/browser/ui/ash/multi_user/user_switch_animator_chromeos.cc
,
Nov 29 2017
The issue described in #14 should have been fixed. Though I'm not sure if it's the same as what was originally reported in #0. Since I could not repro it, I'll close this issue. Feel free to reopen it if you still can see it. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jamescook@chromium.org
, Nov 6 2017