Closed Bug 787810 Opened 7 years ago Closed 6 years ago

My restartless addon crashes Firefox, javascript only


(Core :: Networking, defect, critical)

15 Branch
Windows 7
Not set



Tracking Status
firefox15 --- affected
firefox16 --- affected
firefox17 --- unaffected


(Reporter: ignisvulpis, Unassigned)



(Keywords: crash, testcase)

Crash Data


(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

Wrote and installed a restartless addon into a fresh Firefox Profile.
The addon registers a protocol handler for the scheme "openid".

Actual results:

Most of the times clicking on the "openid" link crashes Firefox even if Firefox has just started.
Sometimes it happens after a few installs of the same addon.
Here is my test page that triggers the crash:
<!DOCTYPE html>
<meta charset="utf-8">
<title>OpenID Consumer</title>

<a href="openid://?response_type=id_token&">Click here to login</a>


Expected results:

A javascript only addon should never crash Firefox.
Confirmed for 15 and 16 (Beta)

bp-fb36d9e4-bc7c-48f9-8965-4d73e2120902 (15)
bp-1a2d29b3-9bec-4da5-958b-d4d012120902 (16)

By a quick Check no Crash on Aurora/Nightly.

Frame 	Module 	Signature 	Source
0 	xul.dll 	NS_NewChannel 	obj-firefox/dist/include/nsNetUtil.h:196
1 	xul.dll 	nsDocShell::DoURILoad 	docshell/base/nsDocShell.cpp:8926
2 	xul.dll 	nsDocShell::InternalLoad 	docshell/base/nsDocShell.cpp:8781
3 	xul.dll 	nsDocShell::OnLinkClickSync 	docshell/base/nsDocShell.cpp:11712
4 	xul.dll 	OnLinkClickEvent::Run 	docshell/base/nsDocShell.cpp:11533
5 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:624
6 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:82
7 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/
8 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/
9 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
10 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:232
11 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:255
12 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3793
13 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3870
14 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3946
15 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:100
16 	firefox.exe 	__tmainCRTStartup 	crtexe.c:552
17 	kernel32.dll 	BaseThreadInitThunk 	
18 	ntdll.dll 	__RtlUserThreadStart 	
19 	ntdll.dll 	_RtlUserThreadStart
Crash Signature: [@ NS_NewChannel(nsIChannel**, nsIURI*, nsIIOService*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIChannelPolicy*) ]
Component: Untriaged → General
Ever confirmed: true
Product: Firefox → Core
Fixed/Progression Range:
Last good nightly: 2012-07-20 (crashes)
First bad nightly: 2012-07-21 (no Crash)

Severity: normal → critical
Component: General → DOM: Core & HTML
Keywords: reproducible
Hardware: x86_64 → x86
Suspected bug:
Bug 774585 - Update GetCodebasePrincipal callers to use the correct "data jar"
Bug 774585 belongs to the working range.
Should it be uplifted to Beta?
No longer blocks: 774585
Depends on: 774585
> A javascript only addon should never crash Firefox.

That's not enforceable.  A javascript only addon, for example, can use ctypes to do whatever it wants.

In this case, the addon's newChannel function is broken.  It returns null without throwing in some cases, which is a violation of the newChannel contract.

We could possibly add a null-check in all NS_NewChannel callers in addition to the existing check for success.  But I'm not sure it's worth the performance hit.
Component: DOM: Core & HTML → Networking
Er, I meant a null-check in NS_NewChannel.  And on other NewChannelFromURI callers.

Or a null check in the IO service when it calls newChannel on the protocol handler.  Same thing.
Can't this one get resolved e.g. WFM as 17 is out?
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.