Closed Bug 236673 Opened 20 years ago Closed 20 years ago

Firefox crashes if there is no profile (import wizard dialog appears)

Categories

(Firefox :: Migration, defect)

Product:
Firefox
Component:
Migration
Platform:
x86
Windows ME
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox0.9

People

(Reporter: bugzilla, Assigned: bugs)

References

Details

(Keywords: crash, regression)

Attachments

(3 files)

Log
4.47 KB, text/plain
Details
Log2
651 bytes, text/plain
Details
Fix for crash
824 bytes, patch
bugs
: review+
Details | Diff | Splinter Review 
Hello, I've tried the latest version of firefox with no profile:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040305 Firefox/0.8.0+

a window that says "Import Wizard" appears for a split second and then closes...
firefox never starts.

Steps to reproduce:

1. download latest firefox nightly
2. Start it without having a profile

Reproducible: always

The build works fine if a profile already exists.
Severity: normal → critical
I'm seeing this on Windows too.

--> All/All
--> Migration
Assignee: firefox → bugs
Component: General → Migration
OS: Linux → All
Hardware: PC → All
Keywords: regression
I'm not getting anything to start (let alone the Import Wizard) unless there is
a pre-existing profile on Windows XP. Could this be related to the pending
change from %AppData%Phoenix to %Appdata%Firefox (or whatever)?
On Mac OS X 10.2.8, starting with no profile, the Import Wizard displays but is
non-functional.  After force-quitting the Import Wizard, Firefox automatically
started (I did not click the dock icon to re-launch) and automatically created a
new profile.  Firefox worked properly after that.
Confirming. Linux - self build from CVS.
With clear profile migration window opens but it's not functional.
Attached file Log — 
./firefox > log.txt
Attached file Log2 — 
./firefox 2> log2.txt
This WFM with the latest nightly on WinXP (2004-03-12).

I think it was probably fixed by Ben with the checkin here:
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/browser/components/migration/src/nsProfileMigrator.cpp&root=/cvsroot
(rev. 1.6 is the relavent entry).

Can anyone reproduce with a new nightly? If not, please mark this fixed.
IMO this bug is a blocker.
"Blocker: Blocks development and/or testing work"
I agree: although Ben does not specifically mention this bug num, the
description for the checkin to nsProfileMigrator.cpp does indicate resolution of
this issue. The problem does in fact seem to be fixed in the builds I have
produced since then. 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040312 Firefox/0.8.0+
(.:MrC:.)
Fixed on Mac OS X as well, using 20040313 Firefox/0.8.0+, even after testing
migration from several different prefs, or none at all.

Since that covers the major platforms, I'll resolve it as fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
confirming WFM on Windows & Linux nightlies
Not fixed in:
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7b) Gecko/20040315
Firefox/0.8.0+ (scragz)

If I don't have a pre-existing C:\windows\Application Data\Firefox containing at
least the registry.dat and pluginreg.dat files, Firefox crashes. With the
required files, then it does not crash even if the profile is under Phoenix (as
mine is) and not under Firefox.


Also still reproducible on build 20040316
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040316 Firefox/0.8.0+

Looking though the CVS log referenced in comment #7, the problem is reportedly
fixed only on Linux and the Mac... but still crashing here on Windows 98 SE

Reopening.
Status: RESOLVED → REOPENED
OS: All → Windows 98
Hardware: All → PC
Resolution: FIXED → ---
OS: Windows 98 → Windows ME
Crash also will occur in XP.
Currently using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b)
Gecko/20040320 Firefox/0.8.0+ (zip build)

crashed if no profile.

previous few nightly builds also crash if no profile exists.


This crash is in:
http://lxr.mozilla.org/mozilla/source/browser/components/migration/src/nsOperaProfileMigrator.cpp#209

The problem occurs if you do *not* have an Opera profile on your system:
nsLocalFile::GetDirectoryEntries() returns a failure nsresult and never fills in
e, leading to the null pointer dereference.
Attached patch Fix for crash — — Splinter Review 
This fixes the crash.
Well done for this one. I installed Opera, and no more crash ! :)
Verified this fixes crashing on launch with my homebuilt Firefox on Win XP SP1.
Patch applied to CVS tree pulled Sat Mar 20 19:24:55 NZDT 2004 (GMT+13), and
mozilla/browser rebuilt.

Eric, you should set a review request on your patch to attract developer
attention. I've set the blocking0.9? flag for the same reason.

Finally, I have never had Opera installed so there is probably another issue
here. I did run a nightly after the initial landing of the migration code and
before the major set of bug fixes were checked in.
Flags: blocking0.9?
WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040321
Firefox/0.8.0+
Attachment #144468 - Flags: review?(bugs)
I'm using the 2003-03-29 build on Windows XP and still seeing this crash
(nothing appears before crashing).  As described in comment 12, one workaround
is to copy everything in "Application Data\Phoenix" to "Application
Data\Firefox" and then firefox will start normally.
Keywords: crash
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040325
Firefox/0.8.0+ (MozJF)

Like comments #15 and #17 say, installing Opera fixes the crash.
what should i do to get this reviewed?
Comment on attachment 144468 [details] [diff] [review]
Fix for crash

r=ben@mozilla.org
Attachment #144468 - Flags: review?(bugs) → review+
anyone in perticular i should get the sr= from?
You don't need sr= on Firefox.  Just find someone to check it in for you now.
who wants to check it in, then? =)
it's checked in. thanks eric!
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox0.9
*** Bug 239270 has been marked as a duplicate of this bug. ***
*** Bug 236607 has been marked as a duplicate of this bug. ***
*** Bug 239011 has been marked as a duplicate of this bug. ***
Flags: blocking0.9?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: