Closed Bug 285544 Opened 15 years ago Closed 15 years ago

Safe Mode doesn't work

Categories

(Toolkit :: Startup and Profile System, defect)

x86
Windows XP
defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: RyanVM, Assigned: rstrong)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050309
Firefox/1.0+

When trying to load Firefox in safe mode in order to verify another bug, I've
found that apparently safe mode no longer works anymore.  I tried to load
Firefox with the following command:
"C:\Program Files\Mozilla Firefox\firefox.exe" -safe-mode

Firefox loads, but the extensions are clearly still loaded as well. 
Furthermore, the extensions appear to be disabled in the Extension Manager even
though they're active.

From what I can tell, this first regressed with the 23-Feb-2005 nightly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see this as well. Nominating.
Flags: blocking-aviary1.1?
After a look at nsExtensionManager.js it appears that removing the entries in
extensions.ini or removing the extensions.ini file itself when starting in
safe-mode will fix this and a quick test where I remove the extensions.ini in
the code for safe-mode does in fact start Firefox with the extensions disabled.
The file is then auto-generated again when starting up normally. I am not sure
of the methodology that was intended to accomplish safe-mode now that the
chrome.manifest files are being used and though it does appear to solve this bug
there may be other ramifications.
The EM doesn't show them as disabled though... I'll see if I can figure it out.
Attached patch patch (obsolete) — Splinter Review
This patch removes the extensions.ini file if it exists when Firefox is started
in -safe-mode. I also changed the code so that it always resturns true when in
-safe-mode in nsExtensionManager_start. When starting up normally the
extensions.ini file is auto-generated so this does not cause any problems with
normal operation.

A couple of other things that I think should be done in
nsExtensionManager.js.in that I haven't included in the patch are:
a) move wasInSafeModeFile outside of the if statement in
nsExtensionManager_start since the var is used by both the if and else
b) around line 697 this._listener = aListener needs to be terminated with a ;

If you would like me to resubmit the patch with these additional items or open
another bug just let me know.
Attachment #176987 - Flags: review?(benjamin)
Comment on attachment 176987 [details] [diff] [review]
patch

grrr... I forgot about global extensions
Attachment #176987 - Attachment is obsolete: true
Attachment #176987 - Flags: review?(benjamin)
Status: NEW → ASSIGNED
Flags: blocking-aviary1.1? → blocking-aviary1.1+
assigned?
has this been fixed by bug 286034 ?
no, this is the exception I get now:

nsExtensionManager:start - (safe mode) failure, catching exception ...
TypeError: this._finalizeEnableDisable is not a function
Attached patch patchSplinter Review
Benjamin - this seems like a simple fix for this bug but it seems a bit too
simple even though it appears to work properly.
Attachment #182912 - Flags: review?(benjamin)
Comment on attachment 182912 [details] [diff] [review]
patch

As a temporary fix for 1.1a, this looks fine. I intend to rework safe mode to
be a lot simpler and less fragile after 1.1a.
Attachment #182912 - Flags: review?(benjamin)
Attachment #182912 - Flags: review+
Attachment #182912 - Flags: approval-aviary1.1a?
Comment on attachment 182912 [details] [diff] [review]
patch

a=asa
Attachment #182912 - Flags: approval-aviary1.1a? → approval-aviary1.1a+
Assignee: benjamin → moz_bugzilla
Status: ASSIGNED → NEW
checked in - thanks timelyx - resolving fix.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Blocks: 293461
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.