Closed Bug 639101 Opened 13 years ago Closed 3 years ago

-safe-mode option does not work anymore in Firefox 4

Categories

(Toolkit :: Startup and Profile System, defect)

x86_64
macOS
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: regression, user-doc-needed, Whiteboard: [addons-testday][rc4][dupme])

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122430

As regression tests have been shown the -safe-mode command line option stopped working between the builds 100930 and 101002.

PASS: http://hg.mozilla.org/mozilla-central/rev/5a2012482a63
FAIL: http://hg.mozilla.org/mozilla-central/rev/286d3026ae20

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5a2012482a63&tochange=286d3026ae20

Josh, could this be related to bug 600711?

IMO this is an important regression which stop users to reset the profile if Firefox cannot be started. Asking for blocking for now to get investigated.
blocking2.0: --- → ?
Whiteboard: [addons-testday]
Whiteboard: [addons-testday] → [addons-testday][rc4]
Latest nightly on OSX (64 bit) works fine for me.
Henrik, what are the steps to reproduce here?  Starting from the command line with -safe-mode seems to work for me (and bent and waldo).
Holding down option while launching WFM also.
I have tested a couple of builds, nightly builds and beta releases and all show the same issue. When -safe-mode is specified the last thing I see is the profile manager. After selecting the profile, Firefox closes immediately. 

Here an example:
/Applications/Firefox-4.0.app/Contents/MacOS/firefox-bin -safe-mode

I haven't tested on other platforms yet, so the newly added dupe is somewhat interesting and not sure if it is directly related.
(In reply to comment #5)
> 
> I haven't tested on other platforms yet, so the newly added dupe is somewhat
> interesting and not sure if it is directly related.

I just made one test on Ubuntu 10.10 with the latest Minefield and safe mode worked for me.

(Still should block if only Mac -- I'd expect lots of profile problems between 3.6 and 4 and safe mode will come in handy.)

Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre
Do you have Firefox configured to show the profile manager by default?
Component: XPCOM → Startup and Profile System
Product: Core → Toolkit
QA Contact: xpcom → startup
At least it is not related to the profile manager ui. When I check don't ask at startup Firefox also closes immediately. I will do some more checks in the next hour to provide you with additional information.
This is somehow related to the ~/Library/Application Support/Firefox folder on my machine. I have tried to start from scratch and renamed the folder to XYZ. The next start of Firefox with -safe-mode as option creates a fresh profile AND the safe mode dialog pops-up. I wasn't able to get into this state again. But more of interest is the next step. I moved the XYZ folder back to revert to my original profiles and the issue even can't be reproduced. Given one of my time machine backups I reverted the Firefox folder to a state from early this morning and now I can reproduce the problem again. I will check for differences of permissions, data, and others now.
I'm now building a debug build in the hope to get more information. Benjamin, if you could tell me lines of code where I would have to set breakpoints I would appreciate it. Not sure yet how much verbose the normal console output is.
With a tinderbox 64bit debug build I get the following output:

WARNING: NS_ENSURE_SUCCESS(rv, 1) failed with result 0x80004005: file /builds/slave/cen-osx64-dbg/build/toolkit/xre/nsAppRunner.cpp, line 3669
WARNING: nsExceptionService ignoring thread destruction after shutdown: file /builds/slave/cen-osx64-dbg/build/xpcom/base/nsExceptionService.cpp, line 197
WARNING: Failed to create timer: file /builds/slave/cen-osx64-dbg/build/dom/base/nsJSEnvironment.cpp, line 3408
--DOMWINDOW == 1 (0x1196b4648) [serial = 1] [outer = 0x0] [url = chrome://mozapps/content/extensions/update.xul]
--DOMWINDOW == 0 (0x1196e6088) [serial = 2] [outer = 0x0] [url = about:blank]
WARNING: not an nsIRDFRemoteDataSource: 'remote != nsnull', file /builds/slave/cen-osx64-dbg/build/rdf/datasource/src/nsLocalStore.cpp, line 312
WARNING: Failed to create timer: file /builds/slave/cen-osx64-dbg/build/dom/base/nsJSEnvironment.cpp, line 3408
WARNING: Failed to create timer: file /builds/slave/cen-osx64-dbg/build/dom/base/nsJSEnvironment.cpp, line 3408
WARNING: Failed to create timer: file /builds/slave/cen-osx64-dbg/build/dom/base/nsJSEnvironment.cpp, line 3408
WARNING: Failed to create timer: file /builds/slave/cen-osx64-dbg/build/dom/base/nsJSEnvironment.cpp, line 3408
And as it looks like when Time Machine processes this folder for a backup, the problem seems to be gone. For now I will turn off Time Machine to keep the folder in a broken state.
Ok, so this only happens when you start Firefox with -safe-mode from within the ~/Library/Application Support/Firefox folder, and the inode of the folder has been changed, i.e. you replaced it with an older Time Machine backup. Not sure what I did initially to bring up this problem. I'm sure that I did no restore from the time machine backup.

The last working build from 100930 shows the following error:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

I'm sure I have filed a similar bug already last year about this specific issue but I can't find it at the moment. Given the above steps clearing the blocking request.
blocking2.0: ? → ---
Flipping user-doc-needed so that SUMO knows about this as it might be an otherwise hard-to-diagnose problem.
Keywords: user-doc-needed
Whiteboard: [addons-testday][rc4] → [addons-testday][rc4][dupme]

This works for me in curent releases

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.