Closed Bug 282644 Opened 20 years ago Closed 20 years ago

[FIX]Crash when using Command-Enter for a URL beginning with an unregistered protocol.

Categories

(Core :: DOM: Navigation, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: moz, Assigned: bzbarsky)

References

Details

(Keywords: crash)

Attachments

(2 files)

Type something like

foo:bar

in the location bar, and then press Command-Enter. Witness crash.
Stack.

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   org.mozilla.navigator 	0x002071fc nsDocShell::DoURILoad(nsIURI*, nsIURI*,
int, nsISupports*, char const*, nsIInputStream*, nsIInputStream*, int,
nsIDocShell**, nsIRequest**) + 0x10c
1   org.mozilla.navigator 	0x00206e5c nsDocShell::InternalLoad(nsIURI*, nsIURI*,
nsISupports*, unsigned int, unsigned short const*, char const*, nsIInputStream*,
nsIInputStream*, unsigned int, nsISHEntry*, int, nsIDocShell**, nsIRequest**) +
0xc34
2   org.mozilla.navigator 	0x001fbd00 nsDocShell::LoadURI(nsIURI*,
nsIDocShellLoadInfo*, unsigned int, int) + 0x60c
3   org.mozilla.navigator 	0x00200658 nsDocShell::LoadURI(unsigned short const*,
unsigned int, nsIURI*, nsIInputStream*, nsIInputStream*) + 0x360
4   org.mozilla.navigator 	0x00020624 -[CHBrowserView
loadURI:referrer:flags:allowPopups:] + 0x238
5   org.mozilla.navigator 	0x0000b940 -[BrowserWrapper
loadURI:referrer:flags:activate:allowPopups:] + 0xe0
6   org.mozilla.navigator 	0x00016994 -[BrowserWindowController
goToLocationFromToolbarURLField:inView:inBackground:] + 0xec
7   org.mozilla.navigator 	0x0001c23c -[BrowserWindowController
handleCommandReturn] + 0xfc
Keywords: crash
Target Milestone: --- → Camino0.9
It's crashing in nsDocShell::DoURILoad() because mContentListener is null. I
believe this happens for the Command-Enter case because we haven't already
loaded about:config (as we do for new tabs), so EnsureContentListener() hasn't
been called.

So the fix is either a null check, or an earlier call to EnsureContentListener().
Status: NEW → ASSIGNED
How about we remove EnsureContentListener altogether and just create the
listener in nsDocShell::Init()?  I see no reason we'd ever want a docshell
around that doesn't have a DSURIContentListener; if nothing else, we need one of
those suckers to load anything into the docshell.
Attached patch Like so, saySplinter Review
Attachment #174642 - Flags: superreview?(jst)
Attachment #174642 - Flags: review?(cbiesinger)
Comment on attachment 174642 [details] [diff] [review]
Like so, say

sr=jst
Attachment #174642 - Flags: superreview?(jst) → superreview+
can this be a non-pointer member instead? (would probably need to AddRef it in
the constructor, so nobody calls delete on it)
It's a refcounted XPCOM object, so it needs to be able to outlive the docshell.
  I could make it a non-pointer member if it shares a refcount with the
docshell, but that's dangerous if the parent listener holds a ref to the
docshell (this last is the reason I left the "set mListener to null in destroy"
code too, though come to think of it, I think it's better to null out the parent
listener in destroy and leave mListener around....)
Comment on attachment 174642 [details] [diff] [review]
Like so, say

the destructor calls Destroy... if Destroy is also called explicitly, or if new
DSURIContentListener failed, you will now crash
Attachment #174642 - Flags: review?(cbiesinger) → review-
Attachment #174697 - Flags: review?(cbiesinger)
-> Boris
Assignee: pinkerton → bzbarsky
Status: ASSIGNED → NEW
Component: Location Bar & Autocomplete → Embedding: Docshell
Flags: review?(cbiesinger)
Flags: review-
OS: MacOS X → All
Product: Camino → Core
Hardware: Macintosh → All
Target Milestone: Camino0.9 → ---
Version: unspecified → Trunk
Priority: -- → P1
Summary: Crash when using Command-Enter for a URL beginning with an unregistered protocol. → [FIX]Crash when using Command-Enter for a URL beginning with an unregistered protocol.
Target Milestone: --- → mozilla1.8beta2
Comment on attachment 174697 [details] [diff] [review]
Address biesi's issues (from IRC too)

good catch on the loadcookie thing
Attachment #174697 - Flags: review+
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 174697 [details] [diff] [review]
Address biesi's issues (from IRC too)

>-    NS_ADDREF(*aLoadCookie = NS_STATIC_CAST(nsIDocumentLoader*, mDocShell));
>+    NS_IF_ADDREF(*aLoadCookie = NS_STATIC_CAST(nsIDocumentLoader*, mDocShell));
NS_IF_ADDREF(*aLoadCookie = nsDocShell::GetAsSupports(mDocShell)) ?
Yeah, good idea.  Did that.
*** Bug 284418 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: