Browser windows do not always open on same workspace |
|||
Issue descriptionVersion 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.
,
Jun 13 2016
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?
,
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.
,
Jun 13 2016
> 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
,
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.
,
Jun 13 2016
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?
,
Jun 13 2016
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.
,
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).
,
Jun 13 2016
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.
,
Jun 14 2016
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.
,
Jun 14 2016
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.
,
Jun 29 2016
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.
,
Jun 29 2016
#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.)
,
Jun 29 2016
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.
,
Jun 29 2016
#13 added in https://codereview.chromium.org/2108933003/#ps60001
,
Jun 29 2016
Awesome, thanks Tom.
,
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
,
Jul 9 2016
,
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 |
|||
Comment 1 by danakj@chromium.org
, Jun 13 2016