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

Issue 619673 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Browser windows do not always open on same workspace

Project Member Reported by thomasanderson@chromium.org, Jun 13 2016

Issue description

Version 51.0.2704.84 (64-bit)
OS: Ubuntu 14.04

What steps will reproduce the problem?
Open chrome by typing "/opt/google/chrome/chrome google.com" in the command line, or by clicking a link in a 3rd party app like thunderbird.

What is the expected output?
A new tab opens only on a browser window for the current workspace, or if there is no browser window for the current workspace, a new one is created.

What do you see instead?
A new tab opens on any browser window.

 

Comment 1 by danakj@chromium.org, Jun 13 2016

Right now it's the most recently used window right? What's your proposed algorithm? Will it take into account windows on "all desktops" as separate from windows on the current desktop? What will it do when there's no window on the current desktop?
Right now, it's just the most-recently used window.

Ideally, it should find the most recently-used window for the current workspace, and open the tab in that.  Otherwise, (even if there are other browser windows in separate workspaces), create a new browser window in the current workspace.

I guess we would also consider an all-workspaces window to also be on the current workspace.

Is this worth implementing, from a UX POV?

Comment 3 by danakj@chromium.org, Jun 13 2016

I wonder if this is something that could be controlled from the command line.

> create a new browser window in the current workspace.

That part is most surely going to annoy some people. I'm sure there's workflows that involve finding links on one desktop and opening them in a browser on another. Which made me wonder about command line flags.

If you are opening a new window on the current desktop, what profile does it use? The profile of the last visited window? Things get a bit hairy there maybe.
> I'm sure there's workflows that involve finding links on one desktop and opening them in a browser on another.

Maybe we could fall back on the old method if there's no browser window in the current workspace?

> If you are opening a new window on the current desktop, what profile does it use?

I think it's just the last used profile
https://cs.chromium.org/chromium/src/chrome/browser/ui/startup/startup_browser_creator.cc?rcl=1465816741&l=739

Comment 5 by danakj@chromium.org, Jun 13 2016

Ya, falling back to an existing window when whenever possible maybe makes things a bit easier.. Do you want to do this kind of thing per profile?

1. On Desktop A using profile X.
2. Move to Desktop B. Most recent window there is profile Y.
3. Open a link.

I assume it opens on Desktop B, which puts it in profile Y.

Just laying out all these types of interactions so they are intentional would probably be nice. I don't mean to prescribe what's the right thing for you here, esp cuz I suspect that is different for different people.
Now that I think about it, there are a lot of variables involved that makes this complex.  I'm afraid to say what I think the "right" thing to do is because it would be difficult to get right... but I think instead of using the last active profile, we should instead use the last active profile for the current desktop, unless there is none, in which case fall back on the old method.

I think this is an orthogonal issue to finding a browser window to use when given a profile.  And, if we decide this change is necessary, it should probably go in a separate CL.

Also, erg@ and sky@ are out today.  Do you know who would be best to add for the UX side of things?

Comment 7 by danakj@chromium.org, Jun 13 2016

Cc: sadrul@chromium.org girard@chromium.org
I thought of it because the window implies a profile, each window is exactly 1 profile. I have often found myself opening CLs in the wrong window for instance which puts it in the wrong profile and now I'm not logged into it and have to try again.

I'm not sure who does linux UX things actually.. Maybe sadrul or girard will know.

Comment 8 by sadrul@chromium.org, Jun 13 2016

I think we should continue to do what we do now. That is what we do on other platforms, and doing it differently on Linux would be confusing (difficult to explain, and extra maintenance burden that I don't think is worth it).
sadrul@ Just a thought.  What if instead of changing the cross-platform code to work with workspaces, we instead just detect a workspace change on Linux (by listening to a PropertyNotify event for _NET_WM_DESKTOP on the root window), and move the windows on that workspace to the top of the BrowserList by using BrowserList::SetLastActive.  This has the added bonus of sorting out the profile problem too.

All we would need to do is iterate through BrowserList::last_active_browsers_, filter the ones that match our workspace using browser->window()->GetWorkspace(), then activate those in reverse order.
sadrul@
So should we go ahead and try the change in #9, or just mark this as WontFix?  I personally believe it would be more intuitive for a tab to open on the same desktop, and it would be a pretty painless change.
I actually doubt it will be a painless change. So I would wontfix. It may be interesting to actually do some measurement of how many users this would affect, and then decide whether to do anything about it.
I put in this patch because I was fed up with running into this issue several times a day
https://codereview.chromium.org/2108933003/

Maybe it's just my workflow, but I usually develop with 4 or more desktops, with Chrome on one monitor and terminal or email on the other.  I frequently switch between desktops and I get annoyed when I open a link and it opens on a browser in a different desktop.
#12 My usual workflow in KDE is to switch workspaces first, then use the pager to move a window to the current workspace (possibly without activating it). Your window order list wouldn't be updated in this case, would it? (Although it works after another workspace switch, so already better than the current behavior.)
If it's not activated, then no.  However, I have a very simple fix for that that I can add to the next patch set.
Awesome, thanks Tom.
Project Member

Comment 17 by bugdroid1@chromium.org, Jul 9 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/edabf4d52846972d359457d563eb5e782bbf8a1d

commit edabf4d52846972d359457d563eb5e782bbf8a1d
Author: thomasanderson <thomasanderson@google.com>
Date: Sat Jul 09 00:27:52 2016

Linux: Reorder browser list on workspace switch

Opening a link from a 3rd party app picks the most recently
used profile/browser to open the new tab in.  Whenever a user
changes workspaces, reorder the browser list such that the
browsers in the current workspace are moved to the top of the
list.  This way, when a user opens a link, it will open in a
browser on the current workspace (if there are any browsers).

BUG= 619673 

Review-Url: https://codereview.chromium.org/2108933003
Cr-Commit-Position: refs/heads/master@{#404544}

[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/chrome/browser/ui/browser_list.cc
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/chrome/browser/ui/browser_list.h
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/chrome/browser/ui/views/chrome_browser_main_extra_parts_views_linux.cc
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/chrome/browser/ui/views/chrome_browser_main_extra_parts_views_linux.h
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/chrome/browser/ui/views/frame/browser_frame.cc
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/ui/base/x/x11_util.h
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/ui/views/views.gyp
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/ui/views/widget/desktop_aura/x11_desktop_handler.cc
[modify] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/ui/views/widget/desktop_aura/x11_desktop_handler.h
[add] https://crrev.com/edabf4d52846972d359457d563eb5e782bbf8a1d/ui/views/widget/desktop_aura/x11_desktop_handler_observer.h

Status: Fixed (was: Assigned)
Project Member

Comment 19 by bugdroid1@chromium.org, Jul 19 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dbf499f5aa00782185d392848204284bde71b448

commit dbf499f5aa00782185d392848204284bde71b448
Author: thomasanderson <thomasanderson@google.com>
Date: Tue Jul 19 03:18:15 2016

Linux UI: Add IsVisibleOnAllWorkspaces()

CL404544 gave precedence to the browsers on the current workspace when
opening a tab in an existing browser session, however it did not take
into account that windows may be on all workspaces.

BUG= 619673 

Review-Url: https://codereview.chromium.org/2158653002
Cr-Commit-Position: refs/heads/master@{#406200}

[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/chrome/browser/ui/browser_list.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/chrome/browser/ui/browser_window.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/chrome/browser/ui/cocoa/browser_window_cocoa.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/chrome/browser/ui/cocoa/browser_window_cocoa.mm
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/chrome/browser/ui/views/frame/browser_view.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/chrome/browser/ui/views/frame/browser_view.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/chrome/test/base/test_browser_window.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/chrome/test/base/test_browser_window.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/mus/native_widget_mus.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/mus/native_widget_mus.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/desktop_aura/desktop_native_widget_aura.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/desktop_aura/desktop_native_widget_aura.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/desktop_aura/desktop_window_tree_host.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/desktop_aura/desktop_window_tree_host_win.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/native_widget_aura.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/native_widget_aura.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/native_widget_mac.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/native_widget_mac.mm
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/native_widget_private.h
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/widget.cc
[modify] https://crrev.com/dbf499f5aa00782185d392848204284bde71b448/ui/views/widget/widget.h

Sign in to add a comment