245584 - Firefox crashes at installation [@ nsGlobalHistory::AddNewPageToDatabase ]

Status: VERIFIED FIXED

(Firefox :: Installer, defect)

Description

[Peter van der Woude [:Peter6]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040602 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040604 Firefox/0.8.0+

Firefox 20040603 AVIARY (zip)
Firefox 20040604 AVIARY (zip)
crash when you start it the first time


Reproducible: Always
Steps to Reproduce:
1.delete profiles/FF dirs
2.Set IE as default browser
3.Open Firefox.exe -> crash before Import manager appears
4.Open Firefox again -> Works, but nothing is imported
(also Try to file a bug at bugzilla, you can't , the login submit doesn't work =
different bug)
Bah...
Actual Results:  
CRASH

Expected Results:  
no crash and proper import

Comment 1

[Doug Wright]

I also get this with the installer build - I filed a talkback report

Comment 2

[Dimitrios]

Wfm after following your steps with official 20040604 branch build taken from
http://ftp36.newaol.com/pub/mozilla.org/firefox/nightly/2004-06-04-09-0.9/Firefox-win32.zip.
Import from IE worked wihout problems.

Comment 3

[Dimitrios]

One more thing: I tested on a win2K/SP3 machine with "power user" privilege. Did
you use a restricted account?

Comment 4

[Peter van der Woude [:Peter6]]

Win2k sp4
no restriction, I'm admin on my own machine

Comment 5

[Dimitrios]

Strange thing is that I cannot reproduce any of the latest three bugs you also
mention in the Mozillazine builds forum (great job btw). I also use Win2K. Since
you make clean install, it's hard to explain the difference. 
And a probably foolish question : is there a chance to exist some nasty entry in
your Windows registry? Or something related to Windows Service Packs?

Comment 6

[Doug Wright]

I'm using XP with admin rights, so its not a Windows 2000-only problem btw.

Comment 7

[Benjamin Smedberg]

Can we get a talback ID, so I can look up the stack?

Comment 8

[Doug Wright]

(In reply to comment #7)
> Can we get a talback ID, so I can look up the stack?

TB74820H
TB74822Y

Comment 9

[Olivier Cahagne]

Attachment: TB74820H data

Comment 10

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040607 
Firefox/0.8.0+ BEAST 00:00 PDT (zip)
Works for me now.
I'm waiting for confirmation by others and will change Status as soon as 
possible

Comment 11

[Peter van der Woude [:Peter6]]

And confirmed, changing to WORKSFORME/RESOLVED

Comment 12

[Kendrick Whitegoat]

(In reply to comment #11)
> And confirmed, changing to WORKSFORME/RESOLVED

Still exists for me:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040607
Firefox/0.8.0+ (zip)

Reopen/verify?

Comment 13

[Peter van der Woude [:Peter6]]

I'm lost.
I have 2 computers side by side with the same setup
One crashes, the other doesn't.
I'll reopen this one and request +0.9 Milestone.

Comment 14

[Doug Wright]

This still exists for me in the nightly from 7th June.

I can reproduce this by simply going to File->Import and trying to import from
IE - its something within the IE migrator...

Comment 15

[Benjamin Smedberg]

The error appears to be in nsGlobalHistory::MarkPageAsTyped which calls
NS_NewURI without checking the result. Simple fix involves adding an
NS_ENSURE_SUCCESS right there.

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

Comment 17

[Benjamin Smedberg]

Attachment: error-check global history

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

br and tr FIXED.

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

rofl.

Comment 20

[Doug Wright]

Let it be said - once you devs put your mind to something....

Comment 21

[Dimitrios]

Guys, just a question if you don't mind: why this bug was shown only in a
fraction  of win32 computers? The answer might also explain other stability
related but hard to confirm bugs. Thank you.

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

Dimitrios - the problem was because NS_NewURI was failing - perhaps it was
failing because there was something about the URL from IE's data that our
networking system couldn't handle? Since this was particular to that URL in that
person's set of typed URLs in IE, it didn't show up for everyone.