Closed Bug 787810 Opened 12 years ago Closed 12 years ago

My restartless addon crashes Firefox, javascript only

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
15 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox15 --- affected
firefox16 --- affected
firefox17 --- unaffected

People

(Reporter: ignisvulpis, Unassigned)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files)

my addon self-issued.xpi
23.46 KB, application/octet-stream
Details
Reporter's Testcase
360 bytes, text/html
Details
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> <html> <meta charset="utf-8"> <head> <title>OpenID Consumer</title> </head> <body> <a href="openid://?response_type=id_token&client_id=https%3A%2F%2Fclient.example.org%2Fcb&scope=openid%20profile&policy_url=https%3A%2F%2Fclient.example.org%2Fusage%2F&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj">Click here to login</a> </body> </html> 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/message_loop.cc:201 8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:175 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
Status: UNCONFIRMED → NEW
Crash Signature: [@ NS_NewChannel(nsIChannel**, nsIURI*, nsIIOService*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIChannelPolicy*) ]
Component: Untriaged → General
Ever confirmed: true
Keywords: crash, reproducible, testcase
Product: Firefox → Core
Fixed/Progression Range: Last good nightly: 2012-07-20 (crashes) First bad nightly: 2012-07-21 (no Crash) Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3a05d298599e&tochange=446b788ab99d
Severity: normal → critical
status-firefox15: --- → affected
status-firefox16: --- → affected
status-firefox17: --- → unaffected
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?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: