User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20060614 Fedora/18.104.22.168-1.2.fc5 Firefox/22.214.171.124 pango-text Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20060614 Fedora/188.8.131.52-1.2.fc5 Firefox/184.108.40.206 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.
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 220.127.116.11, 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).
Apologies, forgot some relevant information: Firefox used (same on host1 and on host2): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20060728 Firefox/22.214.171.124
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.
Bug 296363 is also about the same problem, and the suggested workaround (setting MOZ_NO_REMOTE=1) doesn't work either.
Is this reproducible with the latest Firefox trunk (3) or 2 builds?
Whiteboard: CLOSEME 09/25
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
I just reproduced this between two Ubuntu 8.04 systems, both running Firefox 3.0 Gecko/2008060309
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
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.
I can reproduce it now under Debian too with Firefox 2 (iceweasel in fact).
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.
This is by design and will not be fixed.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago → 8 years ago
Resolution: --- → WONTFIX
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).
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.