(A so-so workaround is to use --user-data-dir=/some/directory to start a new session.)

derat and I talked about this.

Shorter description: run chrome on computer A.  ssh to computer B, with X forwarding 
so that DISPLAY is set to computer A.  run chrome on computer B.  reporter wants this 
to use the chrome on the current display (A) so it makes a new window on computer A.

I understand the use case, but I think this is kinda obscure and confusing; no other 
X apps do this.  Aside from it being more code to support this behavior, it would 
also mean that you can't run Chrome from multiple machines simultaneously, something 
we often do during testing.

Can't you just run "ssh computerA google-chrome $URL" instead?

My read of bug 15781 is that it is the *opposite* of what this bug is asking for.

It says: two computers and I want one instance of chrome on two displays.  An "open
url" should open a new window (or tab) on a new display, but using the same instance.

This bug is trying to say: two computers and two instances of chrome, one on each
display.  An open url should pick the correct instance to use (and it's not).

So I wouldn't merge the bugs, although they are related.


I agree the use case is "kinda obscure".  Most people run X11 just on their local
computer.  Probably the most common case would be ssh'ing into a remote box to run
X11 clients for some reason (like it is on a different network).  I would expect it
to be common with people running with thin clients on a server.  It also might happen
with a user logged in to one computer on different displays (say, if you start up X11
on both vt6 and vt7), or maybe if you use the "user switcher" in recent X11 (I don't
know the mechanism that uses).

About the work-around suggested in comment #1, should I guess that CLI open-url
invocation sends a message down (user-data-dir)/SingletonSocket?  If so, then this
won't let me tunnel the request over ssh transparently.  (In fact, I think it won't
work at all even with a shared file system, since sockets are single-machine.)

About the workaround suggested in comment #2, sshing back to the original host,
that's closer.  But you don't actually know the original host, you just know that
$DISPLAY was setup by ssh to tunnel to The Right Place.  If you do know that place
from out-of-band information, then yes, ssh'ing back works (I just checked).  So
probably the best work-around is to implement a custom open-url command that checks
for local/remote $DISPLAY, then to basically reimplement the Firefox remote protocol
if DISPLAY is remote, or to capture and preserve the hostname.

I'm also running into this problem.  I think there is confusion over what exactly the 
problem is.

Suppose I have two X11 servers a:0 and b:0.

I should be able to execute from a shell:
export DISPLAY=a:0
chromium &
export DISPLAY=b:0
chromium &

That should yield a chromium window on each of those displays.  They could use a 
common processes, or they could run independently and just use locking to share the 
profile.

The suggested workaround of having multiple profiles isn't really helpful - that 
means that I end up with two different sets of bookmarks/etc.  I'd really like to be 
able to have two different chromium instances share the same profile.

I almost thought that this used to work fine a month or two ago.  It is the whole 
reason I switched over from firefox, as firefox also doesn't support having two 
sessions open on different displays using the same profile.  konqueror works fine 
this way, although you do get some issues if you try to modify bookmarks/etc as one 
session can overwrite the settings from the other.

I wanted to offer a use-case as well since I agree that this isn't a common usage 
scenario.

I am logged into my local computer (DISPLAY=:0), and I have chromium running.  So far 
that is VERY normal.

Then I go to work.  From work I use the Google Neatx product to connect into my home 
computer to get access to a desktop there - BUT NOT THE SAME DESKTOP SESSION/DISPLAY 
I WAS USING AT HOME).  So, that has DISPLAY=:123 (some semi-random largish value).  
When I try to run chromium in my NX session it opens the window on my home console, 
which I have no access to.  

Alternatively, if you can get the Google neatx team to come up with a way to attach 
an nx session to an existing X11 display that would work just fine as well.  :)  I 
imagine that anybody who actually uses both of these Google products would be fairly 
likely to run into this problem.

 Issue 29868  has been merged into this issue.

Comment #5 sounds like issue 15781.

Comment #6 sounds more common.  I think we can handle this case by passing 
$DISPLAY through ProcessSingletonLinux.  Then we can throw up the profile-in-use 
dialog or a new dialog with some specific wording for this case.

As in comment #5, I think there's some confusion about what the problem is.
But I think that comment get's backwards what the original bug was trying to report,
and instead is speaking about issue 15781, because it is again
talking about how to get one process pointing at two different displays.  (See the 
disucussion in comment #3).

Comment #6, however, points at the same scenario I was trying to get at in the 
initial bug report.

I posted both #5 and #6 - they are both describing issue 15781 - so this appears to be 
a duplicate of that issue.

I was hoping more for chromium opening multiple windows attached to the same profile, 
rather than just displaying an error.  Half the reason I switched to chromium from 
firefox was that until recently it didn't complain when the same profile was opened by 
more than one process.

Re: comment #10, I agree that comments #5 and #6 pertain to issue 15781.

But that doesn't necessarily mean that this issue is a duplicate of that one.

15781 is about having one process point at different displays.  That's a reasonable
goal to have.

But that's a different goal than trying to get a new action to open on the correct
display, which is what *this* bug is about.

It's OK for chromium to have more than one bug/feature request :-)

How do you define the "correct display" - if it means that when chrome is executed 
that it opens a new windows based on the DISPLAY variable exported in the environment 
then #5 and #6 do pertain to this issue.

I want to have one process accessing more than one display, and when I launch chrome 
from the command line I'd like that process to open a new window on the current 
DISPLAY.  :)

I think there are a lot of different use cases which is why we have so many bugs 
around this general capability.  Some people want to drag and drop between two 
different DISPLAYs, and some people want to open new windows on a particular DISPLAY.

I think that this is in part because X-windows doesn't really distinguish much 
between two physical displays that are bound together on the same desk, and two 
different physical displays that are on different terminals half a world apart.

About comment #12: *yes* i agree there are a lot of use cases.  That's why I think 
it's important to keep different bugs pointed at different use cases, since they 
*may* have different solutions.

To me, issue 15781 is about getting two displays with one process.

This issue 27344 is about selecting the process associated with the current display.

These issues may have the same or different solutions... let's leave that to the 
implementers to decide.  It may be easy to solve one and not the other--for example, 
if there's a global variable with display, fixing 27344 means just setting it 
correctly, while 15781 means replacing it with multiple variables, much more work.

(In fact, Firefox supports 27344 as per comment #1, but I don't know that it supports 
15781.)

Sorry - I wasn't trying to be critical of having multiple issues open.  It just didn't 
seem particularly clear to me what exactly each issue was tracking.  

I can confirm that firefox does not support 15781.

 Issue 33066  has been merged into this issue.

I keep hitting this bug too, because I frequently leave Chrome/Chromium running at 
home, then need to log in remotely using nx/neatx to do something, and I can open 
most apps but *not* Chrome/Chromium, because it opens in the desktop session, not the 
nx session.  See comment #6.

The worst part is that Chrome/Chromium offers no option to *not* reuse the current 
running process.  Firefox has the following option that fixes this issue:

  -no-remote  Open new instance, not a new window in running instance.

luke.hutch: see comment #1

OK, so chromium cannot have multiple instances using the same data dir?  I guess that 
makes sense.

This is a problem for me also, running chrome on a local desktop, and also over a 
remote terminal using neatx. I can't open a new chrome on my "current" display if the 
other display already has chrome open. Chrome on MSWindows can have multiple windows 
open. Could this behaviour be extended to Chrome/chromium on linux on different 
displays over remote terminal connections? The work-around at comment #1 is less than 
ideal, since (I presume) it won't pick up bookmarks, history, etc?

My use-case:
My wife sometimes uses my desktop PC (running Ubuntu), while I use my (much less powerful) Netbook. Because the netbook is basically a thin-client, I spend most of my time SSH'd into my desktop.
If my wife is running chrome and I attempt to run chrome, then rather than getting my own window, my wife sees a new tab appear. I would expect that because DISPLAY is different, that I would get a completely independent process.

wmpalmer: I suggest using different accounts.  Currently your browser history and new tab page will be a mixture of you and your wife's browsing behaviors.

evan: isn't that missing the point?  I'm the only one using any of my machines and this bug is still a real problem for me, I can't use chromium in remote login sessions unless I remember to close all my local browser windows before I move from the local to the remote machine, or unless I kill chromium from the remote machine and re-launch in the remote session.

Running Chromium 7.0.517.44 (64615) Ubuntu 10.10
and NoMachine NX Server Version 3.4.0-14 - LFE

When I connect to the NX Server from my Windows 7 laptop and run Chromium the following two things happen:

1. If Chromium is already running on the server computer a new window launches on that computer.

2. If Chromium is not running the new window opens on my laptop screen.

Is this issue being looked into? It really makes Chromium unusable for anyone running a headless server.

Deprecating HelpWanted label.

If DISPLAY=:1 and I start google-chrome I want the window on diplay :1 not :0
If DISPLAY=:2 and I start google-chrome I want the window on diplay :2 not :0 not:1
what is so hard to understand about this ?? this is how every other X program works.
but not google chrome o no it seeks out an already started process and opens a window on whatever display that was on. rather useless. 

#25 I couldn't agree more. I ran into this bug today and it baffles me that it's so hard to understand that it's actually a bug, not just a missing esoteric feature.

#25 breaks it down to the point. just make it behave like every other X program out there, prettyplease.

(Un-ccing myself from bugs.)

#25 is spot on.  It's amazing to me that this issue still exists in current builds of Chrome.  Is this issue even being worked?

Expanding on tip in #1

I needed access to my bookmarks from remote, so I did this:

ssh -Y computer.already.running.chrome

cp -a .config/chromium/ chrometmp/
rm chrometmp/Singleton*
chromium-browser --user-data-dir=chrometmp

Of course a script could be made selecting temporary dir based on DISPLAY
TMPDIR=chrometmp_${DISPLAY}
cp -a .config/chromium/ $TMPDIR
etc.

A hackish workaround while waiting for the issue to be fixed.

 Issue 175192  has been merged into this issue.

 Issue 175192  has been merged into this issue.

#31 didn't work for me. I still get 'Created new window in existing browser session.' 

I'm running into this when I restart my Linux desktop, which runs Chrome's remote-desktop system.  When I log on the physical machine, Chrome is opening windows on the virtual desktop, not on the physical display.  Any chance of a fix?  Pretty please?  Current "fix" is to do "sudo killall chrome", which can't be good for it's health.

#25, just like other linux applications, please.

I'm having this problem as well with Chrome Remote Desktop. Is a fix in progress?

Apparently there's some confusion as to what this bug asks for. It requests support for a "remote protocol" like firefox -remote so that the remote command-line can open windows in a *local* Chrome process. Hence the comment early on in the discussion, "I think this is kinda obscure and confusing; no other X apps do this."

Many other comments want Chrome to work like any regular X app (the remote command-line should start a *remote* process honoring the $DISPLAY). Since apparently there hasn't been an open bug specifically for that, I have filed  bug 293259 . It's *not* a duplicate of this one (bug 27344).

RE #38:

Bug 15781 (even older than this one) addresses the issue of running side-by-side chromium processes for the same user but different DISPLAYs.  I'd say that 293259 is a duplicate of 15781.

Bug 15781 is for fully-featured side-by-side processes, which is a non-trivial feature request (see the design discussion on that bug).  Bug 293259  is merely about fixing the blatant bug. This won't give you all the features, but it would at least give you a browser window within reach of your mouse.

RE #40:

> This won't give you all the features, but it would at least give you
> a browser window within reach of your mouse.

Or an error message, if you take that interpretation of 293259.  It merely states that you shouldn't open a new window on the original display, not that it should open a new window on the new display.  By that logic you could just detect that condition and tell the user that multiple displays aren't supported and exit.

Meh...  :)

> Or an error message, if you take that interpretation of 293259.

Indeed; but I think that that would already be much better than silently opening a window that I can't see or close. (In particular, it's better if it comes with a stderr message mentioning the --user-data-dir option.)

However, I'm confident that that straightforward bug fix as requested by  bug 293259  would actually be able to provide a functional browser window, albeit with restrictions ("Your profile could not be opened correctly. Some features may be unavailable").

Happened to me as well. Techstop helped

Re. comment #38: As far as I read it, whether the original poster was talking about DISPLAY variables and remote protocols or not, the intent was pretty clear: if you are logged in remotely with display tunneling enabled, then every app you launch from the commandline sends its display back over the remote SSH connection *except* for Chrome/Chromium, which pops up a new window or net tab on the remote display (without even telling you that's what happened), as long as there's already an instance running on the remote display. This is not expected or intuitive behavior, or this bug would not have been filed.

Chrome presumably just needs to watch for and respect changes in DISPLAY between new tab / new window events. Does it really require two separate processes to support two separate values of DISPLAY?

> Does it really require two separate processes to support two separate values of DISPLAY?

See bug 15781 for a discussion of complications in supporting multiple DISPLAY values from the same Chrome instance.


Regarding what the *present* bug requests, note that the "expected result" specified *here* was to open a new tab in the instance already running on the SSH client (!). [Note that "DesktopComputer" was described as the client, "LaptopComputer" as the server. My intuition would be the other way around; maybe that contributes to everyone's confusion.] It was explicitly *not* about having the application on the remote host display back over SSH as you might intuitively expect, but instead about having that remote application tell the local application what to do.

Ah, I did misread it, and that is also a problem I have run into! Thanks for the clarification.

I can also confirm this bug, its very annoying when one uses a remote desktop, also --user-data-dir=/some/directory didn't seem to change the issue here, to open a new window in this remote session instead of a tab in the original one I've to kill the browser in the original session and then it opens as expected. Maybe some flag like --new-session is needed if this is a feature and not a bug ;)

I ssh into my linux machine from a windows machine running an X server. My linux machine has running chrome but it is remote. I also want to start a chrome window on my windows machine - leaving the linux machine sessions alone.

I ended up doing this:
cd ~/.config/google-chrome
mkdir /tmp/chrome2
find . -print | cpio -mpdv /tmp/chrome2 # there was no cp -R in my day!
rm -fr /tmp/chrome2/Singleton*
rm -fr /tmp/chrome2/Session* 
google-chrome --user-data-dir=/tmp/chrome2/


I got a new google-chrome on my windows X server with my bookmarks and even the restore my session option.

Adding default Pri-2

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot