1100900 - Unset MOZ_NO_REMOTE when starting a different application

Status: NEW

(Core :: XPCOM, defect)

Description

[Geoff Lankow (:darktrojan)]

This is an uncommon case, admittedly, but I'm hoping it will get fixed somehow.

When starting, say, Firefox with the -no-remote flag, MOZ_NO_REMOTE=1 is set in the environment. If the user then clicks on a mailto: link and expects Thunderbird to open, Thunderbird sees the MOZ_NO_REMOTE and behaves differently. In some circumstances it shows the "Thunderbird is already running, etc." message instead of opening a new email. (This isn't the only use case but it'd be the most common, I guess.)

I'd like to get the MOZ_NO_REMOTE removed when nsIProcess.run is called, but I'm not sure what else such a change would affect.

Comment 1

[[e-mail]]

You'd have to ensure that the MOZ_NO_REMOTE flag got preserved across a restart of Firefox itself.

I've also heard of the problem in reverse, with Thunderbird started with -no-remote not being able to pass links to Firefox.

At least that's one problem I don't have to worry about in SeaMonkey :-)

Comment 2

[Boris Zbarsky [:bzbarsky]]

I wish we could just drop support for the env var; the command-line argument shouldn't have this issue...

But since we do need to support it, we could reset it in our env during startup, once we get past the point where we care about it.  That would handle any subprocesses we start, via any mechanism.

Comment 3

[Geoff Lankow (:darktrojan)]

(In reply to [e-mail] from comment #1)
> I've also heard of the problem in reverse, with Thunderbird started with
> -no-remote not being able to pass links to Firefox.

I've seen that too, just never realised why before.

(In reply to Please do not ask for reviews for a bit [:bz] from comment #2)
> But since we do need to support it, we could reset it in our env during
> startup, once we get past the point where we care about it.  That would
> handle any subprocesses we start, via any mechanism.

What if the subprocess is a restart of the current process? I assume that would be affected too. Could we remove it from the environment after starting, and add it back if necessary when restarting?

Comment 4

[peter]

I also have this problem with starting up a 'mailto:'

It seems to me that there are 2 separate issues:

1.  The MOZ_NO_REMOTE env variable affects programs other than the one that set it.

2.  Eliminating it causes issues with FF communicating with itself.

I guess this variable had its birth when there was just a single monolithic Mozilla app.

The solution to #1 is to name it uniquely for each Mozilla app.  So, for example, I would suggest renaming the env variable for FF to be MOZ_FF_NO_REMOTE, or even better MOZ_FIREFOX_NO_REMOTE.

That would at least avoid other apps from assuming the variable was for them.  In my case, that includes TB.  Of course, TB should ignore MOZ_NO_REMOTE, and only consider MOZ_TB_NO_REMOTE.  Maybe I'll file a bug for them, too.

Problem #2 is trickier, and I don't know all the things that y'all are trying to accomplish with the env variable, so I don't have a suggestion for that.

But, it seems to me to be a trivial change to rename the env variable so that it is unique the FF product, and that would fix #1, which I and the OP complain about.  I mean, I doubt it's more than a global editor replace.

Comment 5

[peter]

Also, the same suggestion about renaming env variables would apply to the MOZ_CRASHREPORTER* set of variables.

Comment 6

[peter]

(In reply to peter from comment #4)
> complain about.  I mean, I doubt it's more than a global editor replace.

I guess this is obvious to devs, but I realized that probably FF and TB share the code for this, so it's more than just a string change in the code.  Maybe a compile-time switch?