starting remote firefox in X doesn't start new firefox, but triggers new window from local firefox

RESOLVED WONTFIX

Status

()

--
major
RESOLVED WONTFIX
12 years ago
8 years ago

People

(Reporter: hacksaw, Unassigned)

Tracking

1.5.0.x Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.4) Gecko/20060614 Fedora/1.5.0.4-1.2.fc5 Firefox/1.5.0.4 pango-text
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.4) Gecko/20060614 Fedora/1.5.0.4-1.2.fc5 Firefox/1.5.0.4 pango-text

I'm on a local linux box, ssh'ed into a remote box, with X11 forwarding enabled.

If I start firefox on the remote box, I get a new window from my local firefox, which is not what I want, since I want to look at file:///var/www on the remote box.

Reproducible: Always

Steps to Reproduce:
1. In linux, ssh -X to remote box
2. start firefox
3. look at file:///var/www, compare to ls listing on remote box.

Actual Results:  
Wrong directory, it's the one from the local host

Expected Results:  
I should see the one on the host where I issued the new firefox command.

Comment 1

12 years ago
I have the same issue, even when I start firefox with the --display= setting: 

user@host1:~$ ssh -Y user@host2
user@host2:~/firefox$ ./firefox -v
Mozilla Firefox 1.5.0.6, Copyright (c) 1998 - 2006 mozilla.org
user@host2:~/firefox$ ./firefox --display=0:10

Opens up a local (host1) firefox .

Using: Ubuntu 6.06 LTS on both host1 and on host2 , with firefox downloaded from http://www.mozilla.com/firefox/ (not using Ubuntu package). 

Comment 2

12 years ago
Apologies, forgot some relevant information: 
Firefox used (same on host1 and on host2): 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Comment 3

12 years ago
Seems to be the same bug as bug 345900, where it is said that there's an option to avoid that, but it no longer works. Anyway starting a remote firefox should be the default since:
  * The IP address is important (intranet, authentication by IP...).
  * The profile (i.e. the .mozilla/... directory) is different.
This bug prevents the user from being able to browse some web sites.

Comment 4

12 years ago
Bug 296363 is also about the same problem, and the suggested workaround (setting MOZ_NO_REMOTE=1) doesn't work either.

Comment 5

11 years ago
Is this reproducible with the latest Firefox trunk (3) or 2 builds?
Whiteboard: CLOSEME 09/25

Comment 6

11 years ago
I cannot reproduce it with Firefox 2.
closing as incomplete -> no feedback and wfm per comment #6
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 8

11 years ago
I just reproduced this between two Ubuntu 8.04 systems, both running Firefox 3.0 Gecko/2008060309
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
(Reporter)

Comment 9

11 years ago
For the purposes of prioritization, if I need to look at html files in a package on one of the several servers I use, I just can't. It sends the command to my local firefox, which can't see the server filesystem at all, nor should it. In addition, I can't get rid of my local firefox, as these are web applications, and I need to test them from something not on the server.

I can't speak for the majority of people out there, but for me this is a critical bug. 

Comment 10

11 years ago
I can reproduce it now under Debian too with Firefox 2 (iceweasel in fact).

Comment 11

11 years ago
Well, in fact, it seems that the bug cannot be reproduced between a PowerPC Debian machine and an x86_64 Debian machine. That's probably why my test in comment #6 failed.

Updated

9 years ago
Whiteboard: CLOSEME 09/25

Updated

8 years ago
Version: unspecified → 1.5.0.x Branch

Comment 12

8 years ago
This is by design and will not be fixed.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago8 years ago
Resolution: --- → WONTFIX

Comment 13

8 years ago
Actually it seems that this very general bug was more or less fixed with the -no-remote option.

But I think that:
  * How "file:///" (and "file://localhost/") URLs provided as an argument are handled should be documented (bug 662528).
  * There should be a new option to connect to a running instance only when it is on the same machine, since on a remote machine, file:///" URL's and other things may no longer work (bug 662538).
(Reporter)

Comment 14

8 years ago
Why would this behavior be the right thing by default? I would argue it breaks the principle of least astonishment at the most basic level. I start a browser on a remote machine, I expect it to *run* on that remote machine. I didn't ask Firefox to find my browser for me.

Note that in the instance where I was using this, I had two accounts, each with their own, unshared, not really at all alike bookmarks, history, etc. I only used that machine to debug (ironically) my bugzilla installation.
You need to log in before you can comment on or make changes to this bug.