Crash opening "new composer window" to bogus location, after "this type of page can't be edited" dialog

VERIFIED FIXED

Status

()

P3
critical
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: jruderman, Assigned: anthonyd)

Tracking

({crash})

Trunk
All
Windows 98
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm++], FIX IN HAND, PATCH)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Steps to reproduce crash:
1. Ctrl-L
2. Type in http://www.askljdflskajflksjflaksdjflk.asd
3. Select "new composer window"
4. Click "open"

At this point you'll see the (incorrect) error message, "This type of page 
can't be edited".

5. Click ok to error message

Crash in docshell.dll.

Win98, 2000100708.
(Reporter)

Comment 1

18 years ago
Using the same steps with a valid ftp site will crash in jsdom.dll before 
bringing up the error dialog.  With a bogus ftp site, the error dialog comes up 
and makes the editor window go away without crashing.

Comment 2

18 years ago
Easy null-check fix for RTM.
This is crashing in nsWebShell.cpp, line 1005, at
         NS_ENSURE_SUCCESS(mPrefs->GetBoolPref("keyword.enabled", &
keywordsEnabled),
            NS_ERROR_FAILURE);

because mPrefs is NULL.

-> anthonyd
Assignee: beppe → anthonyd
Keywords: crash, rtm

Comment 3

18 years ago
All platforms.
Hardware: PC → All
(Assignee)

Comment 4

18 years ago
setting to m19 to show up on radar.

anthonyd
Status: NEW → ASSIGNED
Target Milestone: --- → M19

Comment 5

18 years ago
shouldn't mPrefs have been initialized?
(Assignee)

Comment 6

18 years ago
Created attachment 16686 [details] [diff] [review]
patch for the bug
(Assignee)

Comment 7

18 years ago
need review, approval, and super review
Whiteboard: [rtm+], FIX IN HAND, PATCH

Comment 8

18 years ago
r=sfraser on the patch.

Comment 9

18 years ago
PDT marking [rtm++]
Whiteboard: [rtm+], FIX IN HAND, PATCH → [rtm++], FIX IN HAND, PATCH
(Assignee)

Comment 10

18 years ago
ok, just need the a= and the sr=
please, anyone?
anthonyd
(Assignee)

Comment 11

18 years ago
hoping kin can give me an sr= for this relatively minor fix for a crasher.

anthonyd

Comment 13

18 years ago
I still don't understand why mPrefs is null at this point...  mPrefs *must* be 
valid or the docShell will crash in lots of different places - since it *never* 
validates mPrefs.

Has nsIBaseWindow::Create() been called on the docshell?  This is the method 
that initializes mPrefs.

Right now I think that this patch is masking a symptom of something else that is 
wrong.

-- rick

Comment 14

18 years ago
rpotts: what's happening here is that nsWebShell::OnEndDocumentLoad() is getting 
called on a webShell whose Destroy method has been called already. The Destroy 
method (which is actually called multiple times) nulls out mPrefs.

I'd be happy with this patch for now, since this is an edge case (window 
destruction after url load failure), and fixing the real problem later.

Comment 15

18 years ago
oh, sweet...  yeah, I agree, lets go with this patch for now.  (sr=rpotts)

I'll keep in mind that notifications to the docshell can happen *after* destroy 
is called...  Maybe I can bulletproof the code some more if/when I dive into 
docshell cleanup again :-)
(Assignee)

Comment 16

18 years ago
rpotts,
quick question, if you give me the sr=, who do i goto for the a=?

thanks,
anthonyd
(Assignee)

Comment 17

18 years ago
fix checked in (cvs comment to follow):
fix for bug # 55750
Crash opening "new composer window" to bogus location, after "this type of page 
can't be edited" dialog
r=sfraser
sr=kin
sr=rpotts
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 18

18 years ago
verified in 10/13 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.