Value of MOZ_NO_REMOTE isn't tested

NEW
Unassigned

Status

()

Toolkit
Startup and Profile System
--
minor
12 years ago
9 years ago

People

(Reporter: sendmail.to, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

We test only if a variable with the name MOZ_NO_REMOTE is set.
If MOZ_NO_REMOTE is 0 we shouldn't do the exactly same thing as if set to 1 or any other value.
http://lxr.mozilla.org/mozilla1.8.0/source/toolkit/xre/nsNativeAppSupportWin.cpp#629



Reproducible: Always
(Reporter)

Updated

12 years ago
Version: unspecified → Trunk

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
"The getenv() function returns the value of the environment variable as a NUL-terminated string.  If the variable name is not in the current environment, NULL is returned."

Basically you could do something like this:
  char *noremote = getenv("MOZ_NO_REMOTE");
  if (noremote && noremote[0] == '1') {
  ...

Of course, that will force MOZ_NO_REMOTE=1, breaking anybody that depends on just MOZ_NO_REMOTE or MOZ_NO_REMOTE=YES/TRUE/etc. I guess you could stricmp() on those values, but is it really worth it? (I bet there's something in the Mozilla codebase that can easily make boolean values out of C strings, but I don't know it off the top of my heads...) :]

Comment 2

12 years ago
We should set no-remoting for any non-blank value of MOZ_NO_REMOTE
(In reply to comment #2)
> We should set no-remoting for any non-blank value of MOZ_NO_REMOTE

Isn't that what we do now (i.e. should this be marked WONTFIX)?

Updated

10 years ago
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
You need to log in before you can comment on or make changes to this bug.