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)
Core
DOM: Navigation
Tracking
()
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: moz, Assigned: bzbarsky)
References
Details
(Keywords: crash)
Attachments
(2 files)
7.50 KB,
patch
|
jst
:
superreview+
|
Details | Diff | Splinter Review |
10.95 KB,
patch
|
Biesinger
:
review+
|
Details | Diff | Splinter Review |
Type something like
foo:bar
in the location bar, and then press Command-Enter. Witness crash.
Comment 1•20 years ago
|
||
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
Comment 2•20 years ago
|
||
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
![]() |
Assignee | |
Comment 3•20 years ago
|
||
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.
![]() |
Assignee | |
Comment 4•20 years ago
|
||
Attachment #174642 -
Flags: superreview?(jst)
Attachment #174642 -
Flags: review?(cbiesinger)
Comment 5•20 years ago
|
||
Comment on attachment 174642 [details] [diff] [review]
Like so, say
sr=jst
Attachment #174642 -
Flags: superreview?(jst) → superreview+
Comment 6•20 years ago
|
||
can this be a non-pointer member instead? (would probably need to AddRef it in
the constructor, so nobody calls delete on it)
![]() |
Assignee | |
Comment 7•20 years ago
|
||
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 8•20 years ago
|
||
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-
![]() |
Assignee | |
Comment 9•20 years ago
|
||
Attachment #174697 -
Flags: review?(cbiesinger)
![]() |
Assignee | |
Updated•20 years ago
|
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
![]() |
Assignee | |
Updated•20 years ago
|
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 11•20 years ago
|
||
Comment on attachment 174697 [details] [diff] [review]
Address biesi's issues (from IRC too)
good catch on the loadcookie thing
Attachment #174697 -
Flags: review+
![]() |
Assignee | |
Comment 12•20 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 13•20 years ago
|
||
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)) ?
![]() |
Assignee | |
Comment 14•20 years ago
|
||
Yeah, good idea. Did that.
![]() |
Assignee | |
Comment 15•20 years ago
|
||
*** 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.
Description
•