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

Status: RESOLVED WORKSFORME

(Toolkit :: Startup and Profile System, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Latest nightly on OSX (64 bit) works fine for me.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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).

Comment 3

[Benjamin Smedberg]

Holding down option while launching WFM also.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 6

[B.J. Herbison]

(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

Comment 7

[Benjamin Smedberg]

Do you have Firefox configured to show the profile manager by default?

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Flipping user-doc-needed so that SUMO knows about this as it might be an otherwise hard-to-diagnose problem.

Comment 15

[Shane Caraveo (:mixedpuppy)]

This works for me in curent releases