xen: Running Firefox remotely via ssh -X actually runs locally.
 

I have a Fedora 8 box with two xen paravirtualized guests. One is CentOS 4.6 and one is CentOS 5.1. Networking among these seems to work fine. The xen guests appear to be just like any other machines on my lan.

When I log in to one of my guests (i.e. machineB) from dom0 (i.e. machineA), via "ssh -X machineB", and fire up Firefox, I expect Firefox to run on machineB and display on machineA's display; just like they were physical machines on the same LAN.

However, that is not what I get. I get Firefox running on machineA rather than machineB and displaying on machineA. I know this because the version of Firefox on machineA is 2.0.0.10 and machineB and machineC have version 1.5.0.12. Also, if I start Firefox on machineB, I expect localhost to be machineB. But, localhost is machineA.

If these were actually different machines on the same lan, and I remotely logged in from machineA to machineB with "ssh -X machineB" and ran Firefox or another X program, I would see the display on machineA but the program would be running on machineB. That's what always has happened. Has it changed?

Interestingly, this is what *has* been happening until recently. It is just today that I observed this weird phenomena.

In fact, if I log in to machineB from machineA and run xterm, gnome-terminal or yumex I get that program running on machineB displaying on machineA. Just Firefox seems to be affected.


I have several specific questions:

1) Why is Firefox running on the (dom0) machine I remotely logged in from rather than the machine I am logged in to?

2) Why did this behavior just change? (I guess this is asking for mind reading or remote viewing or some such, but I would like some insight if it is available.)

3) Is this some new Firefox "feature"?

4) How can I revert to the previous behavior? I mean if I wanted Firefox running on the machine I was sitting at, surely I would have started it there. The fact that I "ssh -X machineB" from machineA and fired Firefox up there would seem to indicate that I want Firefox running on machineB and displaying on machineA.

5) Is this related to the fact that machineB is a paravirtual guest? Would this happen if the machines were physical machines on the LAN?

Thanks,
Phil

First, what you say is hard to believe. Second, it is very hard to elieve or understand. Personally I lack imagination to guess, so maybe some clues will come up if you run xterm, ensure that is run on machineB and displayed on machineA, and then run in this xterm. Let it load with no tabs and close it. Post resulting file "log" here. It will contain each system call (including networking) that original Firefox process will make. Also try doing it without Firefox instances on any of your systems running on this CPU, and with one instance on the machineA. Post both, saying which is which and also describe where Firefox actually runs and where it displays.

Well, Raskin, thank you for your interest. Of course, I didn't say it was easy to believe, I only said it was true. ;)

I performed the first part of your test, as requested, but it produced too much output to post here.

Let me know how to pare this down, and I'll post what you want.



(Please note that I used the names machineA and so forth to simplify the discussion. The actual names you see in transcripts will be:
machineA: frederic, running Fedora 8
machineB: andrew, running CentOS 5.1
machineC: agnes, runing CentOS 4.6)


Thanks,
Phil

When I started this thread, I genuinely believed that my problem was network related, or at least virtual network related. I see now that it isn't. Sorry for putting this thread in the wrong topic. It surely should have been in General or possibly Software.

I seem to have tripped over some formerly unknown (to me) "feature" of firefox.

My network includes a Fedora 8 box (frederic), an Ubuntu 7.04 box (selma), and two virtual guests running on frederic, a CentOS 5.1 box (andrew) and a CentOS 4.1 box (agnes). None of these details really matter, it is just what I have to test with. Which distribution is irrelevant, and physical or virtual is irrelevant. Assuming that this is all linux to linux, X to X, and remote login is via "ssh -X". I have no idea what would happen with other OSs, display protocols, or remote login protocols.

Here's what seems to happen:

If firefox is not displaying on the local machine, and a new firefox is fired up locally, you get firefox running locally.

If firefox is not displaying on the local machine, and a new firefox is fired up remotely, but on the local display, you get firefox running remotely, displaying locally.

If firefox is running and displaying locally, and a new instance is fired up remotely to be displayed locally, a new instance of the local firefox is created and displayed locally. No new remote firefox is actually started.

If firefox is running remotely and displaying locally, and a new firefox is fired up locally to be displayed locally, no new firefox is actually started. A new instance of the remote firefox is displayed locally.

Is this news to anyone else? I never saw it before, and it really confused me. Maybe someone somewhere sees value in it, but I don't.

I have a few questions:

1) Am I demented? Okay, forget that one.

2) Is this a common firefox feature, and I have just never heard of it or is it something new?

3) Is this common knowledge? Have you ever heard of it?

4) Most importantly, how do I cause this to cease? This is aggravating, and I need it to stop. I need to be able to control where my browser is running. I certainly don't want the browser to decide where to run.

Thanks,
Phil

1) No, you are not, as far as can be said from this thread.
2) The feature was first intended for local copies, and is well-known, but you have just checked how strange it works over ssh.
3) Common knowledge (I know it very well and it was the reason I asked you to check different combinations): if you run second Firefox on the same box, it checks if there is another instance running; if yes, it establishes connection with initially running Firefox and asks it to spawn one more window.
Not so common knowledge: specifically, it checks for Firefox running not on the same box, but on the same DISPLAY. Probably it searches for a window with specific properties which are always the same for Firefox instances.
4) How to get rid: you can try to use Xnest. Or xmove. Or Xvnc+vnxviewer. First two are X servers that do very little except passing commands to real X server. So Firefox will run alone on formal X display and alone on the OS copy.. I think it will not find siblings. Another way is to use inner Firefox possibilities. I will just give you a link to MozillaZine thread and the command you should probably execute remotely. Even if that command doesn't work, I think that you will have enough data for good search request (please post corrected version in that case).

http://forums.mozillazine.org/viewtopic.php?p=702985

Thanks for the input, Raskin.

I was well aware that Firefox would run just one instance for many windows for each login session, but I had no idea that it ran only one instance per display regardless of where on the network that one instance was running.

What if I want the cookies and bookmarks and profile and the whole environment of the browser I actually thought I was firing up? I'm just out of luck?

Seems clever to me, where clever is among the worst qualities a program can have.

I quite understand why Firefox would use one instance per login for many browser windows (questions of efficiency and keeping profile data in sync and so forth), but it seems quite poor design to use one instance of Firefox per... per what? per display? per Xserver?

If I read your link and the documentation correctly, the environment variable MOZ_NO_REMOTE will not correct the problem. It gets rid of the undesired behavior as well as the desired behavior of running one instance of Firefox per login. I don't want a new instance of Firefox for each window on my display, I want a new instance of Firefox for each logged on account, particularly logins to different machines.

Basically, I just want Firefox to run where I start it, not somewhere of its own choosing.

An interesting question would be, what if you open up your Xserver up to other users (via xhost +, for instance) and someone else runs an instance of Firefox on your display. Now, you start up a Firefox instance yourself. What actually runs? Do you get your own instance of Firefox, or do you share that instance already displaying on your display?

I can't quote it exactly, but I am reminded of a bit from Kernighan and Plauger's "The Elements of Programming Style" (or "Software Tools" by the same authors) in which they say that a program that tries too hard to know what you want is more hindrance than help. They also say that a program should not surprise, should have reasonable defaults, and quirky, subtle, or unpredictable behavior should be optional.

I assume, though, that few on the Firefox team (according to current practice) has ever heard of K&P or given much consideration to quality programming style.

I will look into your other suggestions, and maybe check out the Firefox support forum. If I find a good answer I will post it here.

Thanks again,
Phil

I just experienced the exact same firefox anomaly yesterday. My temporary workaround since I'm on KDE is to use konqueror for the site I'm trying to run via ssh (which happens to be a localhost-only wiki on the remote machine) which leaves my local firefox free to use as I wish. But I'd certainly like to see the fix if someone comes up with one.

Update: Just googled and found the answer:

http://ubuntuforums.org/showthread.php?p=3154546

After you ssh, run firefox with the '-no-remote' flag.

Hi, DonnieP.

The no_remote flag doesn't work for me. Neither does the MOZ_NO_REMOTE environment variable. Don't know why.

Just to be sure - which one are you using?

The second one is correct. ;)

Sorry, "-no_remote" is a typo. I use -no-remote. It don't work. I just tried again, seconds ago, and it still don't work. (My installation has been updated several times lately, and I was just hoping).