378032 - Firefox display from 2 different servers over X11 forwarding are merged to one process on the first server and no new window is created (tab is added to existing window)

Status: REOPENED

(Core :: Widget: Gtk, defect)

Description

[brent]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

I recently noticed something strange with X11 forwarding Firefox over SSH. I was running X11 on my Mac (OS X Server 10.4.8) and had two separate SSH sessions open to two different Linux boxes (I used the -X flag). I started Firefox on the first box and then subsequently started Firefox on the second box. But instead of starting a new process on the second box a new process was spawned on the first box - I ran top to verify this and there was no Firefox process running on the second box, while there were two on the first ! I tried this a bunch of times and still
the same thing happened. I've also tested this on a Windows box using putty and Xming(or any other X windows client) and still the same result. I have also tried connecting to the Linux boxes using the SSH -Y flag and still the same result.

Reproducible: Always

Steps to Reproduce:
1. SSH -X (or Y) to any linux box that has Firefox installed
2. SSH -X (or Y) to any second linux box that has Firefox installed (while still running firefox on the first box)
3. Notice that the new process that should have fired up on the second box has actually just jumped to the first box as another tab.  No new process actually starts on the first box.
Actual Results:  
Firefox opened a new tab on the firefox window from the first box

Expected Results:  
Firefox should have started a new process on the second box with a seperate window being displayed back to the user. 

It appears to have something to do with X forwarding

Comment 1

[David Mathog]

I just ran into this bug too.  It is insanely dangerous since unless you are aware of it you think the new window is on system B when it is on system A.  In my case the three systems tested were:


Firefox 2.0.0.14 on Solaris
Firefox 3.0.1 on Mandriva 2008.1
Firefox 1.0.5 on Centos 5

All running over putty ssh tunnel to a single Starnet Xwin-32 (8.1.1222) X11 server.  Whichever system started first, then requests from the other two resulted in a new window from the first system starting.  This was easy to see in this case because all 3 systems were running different versions of firefox.

This is a HORRIBLE bug.  If system "A" wants to start its own firefox, it should certainly be able to do it.  If it had to fail, it would be much better if it bombed out with "one firefox is running over ssh tunnel, another one cannot be started", instead of doing what it does now.

Severity should be increased from Normal to Major, or higher.  This bug blocks the function of Firefox on "competing" systems, and it is a potential security problem.

Comment 2

[David Mathog]

Also if machine B does

  firefox http://www.wherever.com/ &

it will open a tab, directed to the specified URL, but running on machine A.
If the URL is not specified, an entirely new window will open.

However, this only happens if the user name on both A and B are the same.  If they differ than A will instead open its own firefox.

Not having looked at the code I'm going to go out on a limb and guess what is going on here:

1.  When firefox starts it looks to see if it is "already running", and if so,
instead of starting a second process, it instructs the first one to open another window or tab.

2.  The WAY it looks to see if it is "already running" involves the string "firefox", the username, and no other modifiers. 

The 2nd step is where things go wrong - since all it checks for is firefox
and the username, it doesn't notice that the request came from a completely different machine.  To fix this it might also check hostname, IP address, MAC,
or some other machine specific identifier.

Comment 3

[dehais]

Mid 2009 and this bug is still present.
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042708 Fedora/3.0.10-1.fc9 Firefox/3.0.10
Bug seen with X11 servers:
- xorg-x11-server-Xorg-1.5.2-6.fc9.x86_64
- Xming 6.9.0.18
- X-Win32 7.1 build 1564

Comment 4

[Tyler Downer [He/Him]]

Moving to x64 linux

Comment 5

[Tyler Downer [He/Him]]

This is a mass search for Firefox General bugs filed against version 3.0 that are UNCO and have not been changed for 200 days.

Reporter, please update to Firefox 3.6.10 or alter. Firefox 3.0 is no longer supported and is no longer receiving updates. After you update, please create a fresh profile, http://support.mozilla.com/kb/managing+profiles, and test to see if your bug still exists. If you still the bug, then please post a comment with the version you tested against, and the problem. If the issue is no longer there, please set the RESOLUTION to  RESOLVED, WORKSFORME.

Comment 6

[Tyler Downer [He/Him]]

No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

Comment 7

[Paul Milliken]

I can reproduce this on my machines.

First terminal:

paul@mog:~$ firefox --version
Mozilla Firefox 3.6.12, Copyright (c) 1998 - 2010 mozilla.org
paul@mog:~$ firefox www.slashdot.org


Second terminal:


paul@mog:~$ ssh -X paul@diablos
paul@diablos's password: 
[paul@diablos ~]$ firefox --version
Mozilla Firefox 3.6.12, Copyright (c) 1998 - 2010 mozilla.org
[paul@diablos ~]$ firefox www.theregister.co.uk


Expected result: Two firefox windows, one running on mog, the other on diablos.
Actual result: One firefox window (running on mog), with two tabs.

Comment 8

[Paul Milliken]

I just did some additional experimenting (in the second terminal):


[paul@diablos ~]$ su -
Password: 
[root@diablos ~]# firefox www.bbc.co.uk
[root@diablos ~]# exit
logout
[paul@diablos ~]$ su
Password: 
[root@diablos paul]# firefox www.bbc.co.uk


The first attempt created a new firefox process (running as root on diablos). I then closed that firefox, and did the second part, which re-used the original window from mog.

Comment 9

[Paul Milliken]

After updating to 3.6.13, and using different boxes to previously (one Fedora 13, other CentOS 5.5, firefox installed from corresponding repositories)

First terminal:

[paul.milliken@balamb ~]$ uname -a
Linux balamb.XXXX 2.6.34.7-61.fc13.i686.PAE #1 SMP Tue Oct 19 04:24:06 UTC 2010 i686 i686 i386 GNU/Linux
[paul.milliken@balamb ~]$ firefox --version
Mozilla Firefox 3.6.13, Copyright (c) 1998 - 2010 mozilla.org
[paul.milliken@balamb ~]$ firefox www.slashdot.org

Second terminal:

[paul.milliken@balamb ~]$ ssh -X paul.milliken@appserv2
paul.milliken@appserv2's password: 
[paul.milliken@appserv2 ~]$ uname -a
Linux appserv2.XXXX 2.6.18-194.11.1.el5 #1 SMP Tue Aug 10 19:09:06 EDT 2010 i686 i686 i386 GNU/Linux
[paul.milliken@appserv2 ~]$ firefox --version
Mozilla Firefox 3.6.13, Copyright (c) 1998 - 2010 mozilla.org
[paul.milliken@appserv2 ~]$ firefox www.theregister.co.uk


Expected result: Two firefox windows, one running on balamb, the other on appserv2.
Actual result: One firefox window (running on balamb), with two tabs.

Comment 10

[Paul Milliken]

Attachment: Initial patch attempt for discussion

So, I finally had a chance to delve into the source and try to figure this out for myself. The problem seems to come from the use of the LOGNAME environment variable as a "unique" identifier. This explains why remote machines on which you have a different user name don't result in the problem, and the difference between using "su" and "su -" in some of my earlier experiments.

So, I've made a slight tweak. Instead of using LOGNAME, I've made the code concatenate LOGNAME and HOSTNAME to make something that should be more unique. This tweak is attached as a patch against the mozilla-central mercurial repository. I don't really expect this patch to be used as-is. It is simply a suggested approach that could be used. It does have the desired effect in the limited testing I've performed.

Comment 11

[Paul Milliken]

Any chance of this getting picked up at some point?

Comment 12

[dehais]

A way to avoid this strange behaviour of firefox, is to use the -no-remote option.

Comment 13

[David Mathog]

(In reply to comment #12)
> A way to avoid this strange behaviour of firefox, is to use the -no-remote
> option.

The documentation argues against that: 

http://kb.mozillazine.org/Opening_a_new_instance_of_your_Mozilla_application_with_another_profile

says specifically not to use this switch with the default profile, which is I suspect, what 99.9% of us are using.  

I think Paul in comment 10 is on the right track - the application needs to keep track of which machine started it and not treat requests from other machines the same as from the originator.  Ideally Firefox wouldn't even reveal to a second originator B that it was already running on A, even when both are visible on X11 display on C, but it would reveal to processes by the same owner on A that it was already running, so that, as now, it would open new windows rather than starting a second process on A. 

On a related point, somewhere on the firefox window when running A->C the dispaly should indicate the hostname of A.  So that it would be obvious which firefox was from which machine.

Comment 14

[Paul Milliken]

This issue still occurs in Firefox 10.0 (I'd altered the way I work and wasn't generally encountering it (mostly by using Chrome for some things), but recently hit it again to environment changes).

It has been over a year since I proposed a potential approach to solve this. Is there ANY chance AT ALL of this being fixed?

Comment 15

[Harry Goldschmitt]

It's been 4 years and I'm still seeing it on the latest CentOS6 and CentOS7 Firefox. The hostnames do display, but that's of little use when trying to get to files on different servers.

I can't believe this has taken over 9 years to get fixed. I know of no other X application that has this flaw. It is extremely dangerous.

In my case I'm using Firefox to install Linux systems via a Dell iDRAC virtual ISO image. I ended up wiping out a server because I installed an undesired ISO image on a 3rd server without noticing the image was picked up from the wrong host. It took most of a day to figure out what was wrong.

Comment 16

[Eric.aka.darth_vader]

I agree. I am experiencing this bug on CentOS7 and Fedora 22. 

I think this is a very serious bug and needs to be looked into!

Comment 17

[Danoz]

It's been 11 years now, still waiting for this simple but annoying bug to be fixed. A patch was suggested SEVEN years ago, what's the hold up?

Comment 18

[Panos Astithas (he/him) [:past] (please ni?)]

I'm reopening this only because it's not clear the right people have had a chance to look at it, but given how old this bug is, they may in fact already have. The comment about using -no-remote is a fine way to make this use case work. I bet this is the main reason profile remoting was introduced in the first place and the only reason we still keep it around today.

If someone can take a look at the patch and determine whether it is something we could take, that would be great.

Comment 19

[David Mathog]

-no-remote is backwords.  "No remote" should be the default state, as the average user is not expecting a browser to work that way.  If some advanced user really wants the current behavior, and I cannot imagine why they would, then let them specify -remote.