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: