151863 - mozilla script grabs wrong existing process

Status: RESOLVED EXPIRED

(Core Graveyard :: X-remote, defect)

Description

[Michael Toomim]

If I run multiple mozilla process on a single X server, from different machines,
the mozilla script will often open a new window using the wrong existing
process.  There is no way to control this.

For instance, I have IMAP mail filters set up on a remote machine's mozilla
mail, so I run that program to filter my mail while using a local mozilla mail
process to actually read my mail.  But, when I run 'mozilla' on my local
machine, it opens a new window using the remote mozilla process!

This is bad because it is slow and causes invalid results.  Many applications
(like eclipse) try to use mozilla for their html help system, and run mozilla on
url's like "localhost:23455" and "file:///home/....".

A big problem is that when the mozilla script opens one of these url's with a
remote process, the user gets an error without having any way of knowing that
the error was caused by mozilla running from the wrong process.   The only
visible difference between a remote and local process from the user's
perspective is that a remote mozilla window responds slower... which just looks
like mozilla is slow.

To fix this, I propose:

a) That the mozilla script should attempt to find a local process before using a
remote process.

b) That there be an option in the mozilla script for disabling the "use existing
process" trick.

Comment 1

[Matthias Versen [:Matti]]

-> cls 

Comment 2

[hacker formerly known as [e-mail]]

The standard mozilla build script does not attempt to attach itself to a remote
process so you must be referring to the RPMS scripts.  Over to blizzard.

Comment 3

[Michael Toomim]

I'm not sure what RPMS means, but just to make sure, let me add that I'm using a
debian system (not redhat).

Comment 4

[Andrew Schultz]

you are using the package from debian, right (rather than an official Mozilla
build)?  I think the debian package uses the same script as RPM

Part of the problem is that xremote distinguishes bewteen different users, but
not profiles (the remote process has a different profile than the local one, right?)

You can easily prevent the script from opening a new window off an old process
by passing it the profile explicitly:

mozilla -P local_profile

however, if local_profile is already running, Mozilla will bring up the profile
manager because you aren't allowed to have 2 separate processes for the same
profile (to prevent profile corruption).

A workaround would be to run the remote Mozilla as a different user so that it
would grab the correct process.  I think that would do what you want, although
it's a rather hackish solution.

Comment 5

[Andrew Schultz]

I filed bug 151909 (xremote handling of profiles) which would help out here.

Comment 6

[Andrew Schultz]

*** Bug 159504 has been marked as a duplicate of this bug. ***

Comment 7

[Andrew Schultz]

*** Bug 241897 has been marked as a duplicate of this bug. ***

Comment 8

[Kenneth Herron]

Is this still a valid issue? The current mozilla-xremote-client utility takes
optional username and profile arguments.

Comment 9

[Andrew Schultz]

That helps, except that the startup script doesn't actually handle profiles. 
And it still doesn't make Mozilla clairvoyant, which seems to be what the
request is here.

There's also a MOZ_NO_REMOTE environment variable you can set that might help.

Comment 10

[Bob Fischer]

Look, I'm not asking for Mozilla to be clarivoyant, nor do I see why it's so
hard.    Mozilla can find other Mozillas running on the same X-terminal, as
determined by the X server passed to it in, eg, the DISPLAY veriable.  It should
also be able to find other Mozillas running on the same machine, through some
non-X lock file or PID file or what-not.

SO... when you start up, look for another Mozilla that is running on the same
DISPLAY and on the same machine as the startup script.  If you find it, pass the
reqeust to that Mozilla.  Otherwise, start a new one.

Comment 11

[Andrew Schultz]

> SO... when you start up, look for another Mozilla that is running on the same
> DISPLAY and on the same machine as the startup script.

doing that /is/ hard.  The host running the process is not part of any standard
X property, so distinguishing between processes started from the local and
remote hosts is not possible.  Consider already having two Mozilla processes
(one local, one remote).

And if it did somehow work, what happens if you then want the other behavior
(use X-remote to get to the remote Mozilla process and bypass the local one)?

Comment 12

[Michael Toomim]

You can actually solve that problem pretty easily by having Mozilla set an X property on the windows it 
creates with a value of the host they were run from. Then the script can check this value.

As for your second question, I have two answers:
A) I don't think you'd ever need the script to grab the remote process. If the user wants to open a 
window from the remote process, he/she can go to one of the windows and click Ctrl-N.
B) You can add an argument to the script saying which host's process to use. I think it already has 
something like this.

Comment 13

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 14

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 15

[Andrew Schultz]

*** Bug 337510 has been marked as a duplicate of this bug. ***