New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 608712 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Dec 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Windows opened by a profile extension from another profile's desktop don't open on the active desktop

Project Member Reported by gab@chromium.org, May 3 2016

Issue description

Version: 49.0.2623.111 (Official Build) (64-bit)
OS: Chrome

What steps will reproduce the problem?
(1) Have 2 profiles on Chrome OS with the hangouts extension in profile #2
(2) Login to profile #1
(3) Login to second profile #2 (i.e. CrOS multi-profile)
(4) Move a window from profile #2 to #1's desktop (right-click window + "Move Window to Profile #1")
(5) Click the hangouts extension icon in that window

What is the expected output?
Hangouts window pops open on the desktop it was invoked from (profile #1's)

What do you see instead?
Nothing (in practice, the window does open but on profile #2's desktop -- which isn't the active desktop).

Similarly: pressing Ctrl-N while focusing profile #2's window on profile #1's desktop opens a window for profile #1 while I'd expect it to open another window for profile #2 on profile #1's desktop.
 
Cc: abodenha@chromium.org skuhne@chromium.org
Owner: x...@chromium.org
-> xdai@ for multi profile issue.

+skuhne@ who is the original author of multi profile.

I'm not sure what we can do about this because we do not know the intention of "an app creating a new window", unlike browser window case. It could be just opening due to some event, or due to restart, or due to a user action, but these information isn't available to chromeos.

Ctrl-N is different issue, and we can fix this by using the active window's profile. Could you please file a separate bug?

Comment 2 by gab@chromium.org, May 3 2016

Summary: Windows opened by a profile extension from another profile's desktop don't open on the active desktop (was: Windows opened by a profile from another profile's desktop don't open on the active desktop)

Comment 3 by gab@chromium.org, May 3 2016

 Issue 608840  now tracks the ctrl-N part of this (and re-labeled this one to be extension specific).

Thanks,
Gab
Ctrl+N is fixable (and used to work if I remember correctly).

Apps - yes, there was a problem. It is possible to route all app creations to the current user, but that is incorrect. Since apps can show up long after they were started (not even mentioning installation and updates), it is not easy (if even) to figure out where to show it.

Back when we created the "visiting windows" we said that there might be some cases which do not properly work and for that we had the special acknowledgement for the user to acknowledge that there might be edge cases.
  

Comment 5 by x...@chromium.org, May 5 2016

Based on #4, I think it's a 'WontFix'?

Comment 6 by gab@chromium.org, May 5 2016

Can't we do something about the use case of clicking the extension icon from the window? (e.g. remember the user just interacted with that extension on that desktop and within some timeout handle window open requests from that extension on that desktop?).
Status: WontFix (was: Assigned)
Based on #1 and #4, I agree there is not a clear way to fix this problem as there are many cases that "an app can create a new window" and it's hard to tell the app's intention where to put the window. So I think always put the new window back to its owner's desktop sounds reasonable.

Sign in to add a comment