500553 - remote X server instance contaminates subsequent local instances on laptop

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Rob]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc10 SeaMonkey/1.1.16
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc10 SeaMonkey/1.1.16

If I ssh to my server from my laptop and start seamonkey (sending the display back to the laptop), then concurrently fire up a local instance of seamonkey on the laptop, the system thinks they are both running from the server...as both windows identify themselves as the server instance and both have my preferences/bookmarks/etc from the server...Hell, if I search url file:/// on the laptop instance it even gives me the root directory tree from the server, not the laptop.

This is totally inappropriate program behavior.  

Reproducible: Always

Steps to Reproduce:
1. from laptop ssh -X uber
2. on uber type seamonkey &
3. open xterm on laptop
4. in local xterm seamonkey &



Actual Results:  
both windows think they are running from the server uber

Expected Results:  
url file:/// on uber instance should return server directory tree
url file:/// on laptop should return local directory tree...it doesn't

Comment 1

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v2.0a3 / current v2.0b1pre?

Comment 2

[Rob]

Probably should have mentioned in original post, this behavior is seen in a client server environment of fully patched fedora 10 linux (x64 laptop) and (i386 server).

Are V2.x RPMs available for both i386 and x64 that will work in the Fedora 10 distro without requiring non-distro dependencies?

Comment 3

[lenochod]

(In reply to comment #2)
> Are V2.x RPMs available for both i386 and x64 that will work in the Fedora 10
> distro without requiring non-distro dependencies?

rpm package (This aren't stable enough for everyone's daily use yet but for testing only).

http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/2.0a3/contrib/FC_RPMS/

==========================================================================

                         System Requirements

==========================================================================

* Linux

   - The following library versions (or compatible) are required:
     glibc 2.3.2, X.org 1.x, GTK 2.x, fontconfig, pango 1.10, libstdc++ 6.
     Red Hat Enterprise Linux 5, Fedora Core 6, ubuntu 6.10 ("Edgy"),
     Debian "Lenny" (testing), and openSUSE 10.2 (or later) installations
     should work.

Comment 4

[Tony Mechelynck [:tonymec]]

If you try to start a new SeaMonkey instance while there is one already running, normally you will get a new window in the old instance, and running in the same profile.

To avoid that, start the new instance with the -no-remote command-line switch. It MUST then also use a different profile (you will probably also need to use either -ProfileManager or -P <profilename> [replacing <profilename> by the profile name] on the command-line).

Comment 5

[neonsignal-mozilla]

I can confirm this behaviour for the version of Firefox in Debian Squeeze (Iceweasel 3.5.16).

reproducing:
1. start a local copy of Firefox
2. ssh into a remote machine (with X11 forwarding)
3. start a remote copy of Firefox
The second copy of Firefox will not start; instead a new window of the first instance will be opened.

Although this behaviour is sensible when both instances are on the same machine, it is unexpected when the instances are being run from different machines.

The workaround is to use '-no-remote'; I don't see that it needs a different profile since it is on a different machine anyway, so there should be no shared data. The only common resource is the X server on the local machine.

Comment 6

[Philip Chee]

FYI: On trunk you can use -new-instance instead of -no-remote.

Comment 7

[Phoenix]

Closing based on Comment 6

Comment 8

[neonsignal-mozilla]

Does this mean that the default behaviour of a remote invocation (with a shared X display) will still open a window on the local instance? What is the use-case where the remote invocation shouldn't start a remote instance (maybe if there was shared secondary storage of profiles)? It seems to me that the default is counter-intuitive (ie, it is not immediately obvious to a user that they are running the browser on a different machine to the one they started it on). Maybe I am misunderstanding the intended purpose of the 'no-remote' flag, but it seems inverted to me. Can someone explain in more detail?

Comment 9

[Phoenix]

https://developer.mozilla.org/En/Command_Line_Options#-no-remote, Bug 650078, Bug 716110