bizarre X11 forwarding behaviour?

[Fritz Wuehler]

Guys I am having a difficult time believing my eyes on this one. I've got
X11 forwarded over SSH from a remote system running firefox. When I start
firefox on my local system even specifying the path to my executable in a
terminal window

/usr/bin/firefox

firefox starts from the remote system! I could see this because on my local
and remote system have different versions of firefox. I cannot get my local
version of firefox to run until all forwarded versions of the remote system
are closed. If I start firefox on my local system first then I cannot get a
remote firefox to start until the local one's finished! Anyone got an idea
what in the blazes is happening?

[Dag-Erling Smørgrav]

Fritz Wuehler <fr...@spamexpire-201202.rodent.frell.theremailer.net>
writes:

> Guys I am having a difficult time believing my eyes on this one. I've
> got X11 forwarded over SSH from a remote system running firefox. When
> I start firefox on my local system even specifying the path to my
> executable in a terminal window /usr/bin/firefox firefox starts from
> the remote system!

This is intended behavior. When you start Firefox, it queries the X
server for existing instances, and if it finds one, instead of starting
a new instance, it sends the existing one a signal telling it to open a
new window.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Chris Dodd]

=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <d...@des.no> wrote in
news:86wr7yi...@ds4.des.no:

Note that you can disable this behavior by using the -no-remote option
to firefox. This will cause it to always open a new instance even firefox
is already running on some other window.

-chris

[Fritz Wuehler]

Thank you for the explanation. That is seriously broken behavior. I'll try
installing another browser. The scenario this happened is I have a firefox
session running on a remote machine with X forwarding because it has a web
server on it that is not accessible outside the LAN.

On my local system I have a tor instance running and firefox configured with
torbutton and privoxy. Once I use the webserver on the remote machine I
can't get to my copy of Firefox that has access to tor on the local
system, or if I start the local copy of firefox with tor I can't get to the
webserver on the remote system.

I'll post something on the tor list and maybe they can help the firefox devs
pull their heads out of their ass.

[Dag-Erling Smørgrav]

Fritz Wuehler <fr...@spamexpire-201202.rodent.frell.theremailer.net>
writes:

> Dag-Erling Smørgrav <d...@des.no> writes:
> > This is intended behavior. When you start Firefox, it queries the X
> > server for existing instances, and if it finds one, instead of
> > starting a new instance, it sends the existing one a signal telling
> > it to open a new window.
> Thank you for the explanation. That is seriously broken behavior.

No, it's actually the only sensible behavior in 99% of the cases. If
you really want a new, separate instance, use -no-remote.

> I'll try installing another browser.

I think you'll find that they all work the same.

> I'll post something on the tor list and maybe they can help the
> firefox devs pull their heads out of their ass.

Seems to me you're the one in need of head-pulling.

[Simon Tatham]

Dag-Erling Smørgrav <d...@des.no> wrote:
> No, it's actually the only sensible behavior in 99% of the cases. If
> you really want a new, separate instance, use -no-remote.

It's reasonably sensible behaviour when the two putative Firefoxes are
running on the same host, since that avoids the problems of two
separate Firefoxes concurrently accessing a single state directory
(history, bookmarks etc). But I can't see why it's obviously what you
want in the OP's case, where the two Firefoxes are running on
different hosts and the only thing they have in common is that they're
opening windows on the same X display.

I think the behaviour in the case of remote X clients is less likely
to be intentional, and more probably it's an unintended side effect of
having the detect-existing-Firefox-and-talk-to-it mechanism work
through the X server. If the mechanism had been implemented via (say)
Unix-domain sockets instead, then it would only happen between
Firefoxes running on the same host, and ones on different hosts
connecting to the same X server would just ignore each other.
--
Simon Tatham "You may call that a cheap shot.
<ana...@pobox.com> I prefer to think of it as good value."

[Owen Dunn]

Simon Tatham <ana...@pobox.com> writes:

> Dag-Erling Smørgrav <d...@des.no> wrote:
>> No, it's actually the only sensible behavior in 99% of the cases. If
>> you really want a new, separate instance, use -no-remote.
>
> It's reasonably sensible behaviour when the two putative Firefoxes are
> running on the same host, since that avoids the problems of two
> separate Firefoxes concurrently accessing a single state directory
> (history, bookmarks etc). But I can't see why it's obviously what you
> want in the OP's case, where the two Firefoxes are running on
> different hosts and the only thing they have in common is that they're
> opening windows on the same X display.

It's usually what I want in this situation. When a random application
on a remote machine wants to pop up a web browser to get me to look at
a web site (perhaps I clicked a link in an email) I don't want to end
up with another firefox, I want the link to open in the one I've
already got here. (Usually with X forwarding the last thing I want is
for a big heavy GUI application to be running over it!)

(S)

[Dag-Erling Smørgrav]

Simon Tatham <ana...@pobox.com> writes:
> I think the behaviour in the case of remote X clients is less likely
> to be intentional, and more probably it's an unintended side effect of
> having the detect-existing-Firefox-and-talk-to-it mechanism work
> through the X server. If the mechanism had been implemented via (say)
> Unix-domain sockets instead, then it would only happen between
> Firefoxes running on the same host, and ones on different hosts
> connecting to the same X server would just ignore each other.

Unix domain sockets might not play well with NFS-mounted home
directories, memory-backed /tmp etc.

[Fritz Wuehler]

> Note that you can disable this behavior by using the -no-remote option to
> firefox. This will cause it to always open a new instance even firefox is
> already running on some other window.
>
> -chris

Thank you,

[Allistar]

Fritz Wuehler wrote:

> Dag-Erling Smørgrav <d...@des.no> wrote:
>
>> Fritz Wuehler <fr...@spamexpire-201202.rodent.frell.theremailer.net>
>> writes:
>> > Guys I am having a difficult time believing my eyes on this one. I've
>> > got X11 forwarded over SSH from a remote system running firefox. When
>> > I start firefox on my local system even specifying the path to my
>> > executable in a terminal window /usr/bin/firefox firefox starts from
>> > the remote system!
>>
>> This is intended behavior. When you start Firefox, it queries the X
>> server for existing instances, and if it finds one, instead of starting
>> a new instance, it sends the existing one a signal telling it to open a
>> new window.
>
> Thank you for the explanation. That is seriously broken behavior.

It's not the only cuplrit of this. OpenOffice and LibreOffice do similar
things. More annoyingly, so do parts of KDE (in particular the monstrosity
that is akonadi).
--
A.

[Stuart Barkley]

> installing another browser. The scenario this happened is I have a
> firefox session running on a remote machine with X forwarding
> because it has a web server on it that is not accessible outside the
> LAN.

You may want to try the poorly documented profile functionality in
Firefox.

At the command line type "firefox -ProfileManager" and create a new
profile. Then you can use "firefox -P <profile>" to start up a
specific instance (put these in menu entries or wherever you want).

I run multiple local Firefox instances fairly often.

One profile will use the local network connection for everything.

Other profiles use various ssh socks tunnels (DynamicForward) to
browse other locations. This also has better performance since
instead of the X protocol being tunneled it is just tunneling the
connections to the web sites. You might also want to set
network.proxy.socks_remote_dns in Firefox so dns lookups happen
through the socks connection and you can see the remote name space.

In some cases I'm proxing out of networks where I don't want
monitoring, filtering or other diddling with my web traffic
(conferences, cafes, hotels, etc).

In other cases I will be proxied into isolated networks to debug
hardware things via embedded web interfaces (switches, pdus, imm
systems). This sounds like your situation.

I also have a separate profile which has the password manager turned
on. Ordinarily I don't store passwords in the browser, but in this
profile I have a few passwords for vendor support sites saved.

Each profile has a complete independent Firefox configuration
(separate bookmarks, separate cookie settings, separate security
policies). Mostly this is good for me.

Stuart Barkley
--
I've never been lost; I was once bewildered for three days, but never lost!
-- Daniel Boone

[Nomen Nescio]

Thanks for the workarounds guys!