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.
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.
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
Hardware: PC → All
setting to m19 to show up on radar. anthonyd
Status: NEW → ASSIGNED
Target Milestone: --- → M19
shouldn't mPrefs have been initialized?
need review, approval, and super review
Whiteboard: [rtm+], FIX IN HAND, PATCH
r=sfraser on the patch.
PDT marking [rtm++]
Whiteboard: [rtm+], FIX IN HAND, PATCH → [rtm++], FIX IN HAND, PATCH
ok, just need the a= and the sr= please, anyone? anthonyd
hoping kin can give me an sr= for this relatively minor fix for a crasher. anthonyd
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
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.
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 :-)
rpotts, quick question, if you give me the sr=, who do i goto for the a=? thanks, anthonyd
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
verified in 10/13 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.