Closed Bug 1426562 Opened 2 years ago Closed 7 months ago

Creating new Response() in add-on crashes the tab


(Core :: DOM: Core & HTML, defect, P2, critical)

57 Branch



Tracking Status
firefox-esr60 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed


(Reporter: speed, Assigned: perry)


(Blocks 1 open bug)


(Keywords: crash, testcase)

Crash Data


(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

In my browser extension (add-on) JavaScript code, I attempted to create a Response object by calling new Response().

Actual results:

The tab crashed and showed me the page: "Gah.  Your tab just crashed."

Expected results:

A Response object should have been created.  Calling new Response() from the Dev Console does not crash the tab.
Severity: normal → critical
Crash Signature: [@ mozilla::dom::ChannelInfo::InitFromChromeGlobal ]
Has STR: --- → yes
Component: Untriaged → DOM
Ever confirmed: true
Keywords: crash, testcase
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Attached file
Looks like this is also crashing on android with a nullptr global.

Probably what we want to do is:

1. Make Response::Constructor throw InvalidStateError if the global is nullptr.
2. Only call InitFromChromeGlobal if we don't have a window, but we do have a system principal
3. Otherwise, let the response get created but without any channel security info
Priority: -- → P2
This still crashes periodically in Fennec, but usually it is a single installation crash.
Component: DOM → DOM: Core & HTML
Duplicate of this bug: 1540109

Based on the stack from we're hitting this release assert:

Which seems to suggest this codepath should only be usable from browser/Firefox code, not from add-ons. See also and comment #2.

:hsinyi, based on the steps in the dupe (bug 1540109) this is blocking people from releasing Firefox add-on updates. Any chance it could be prioritized?

Workaround in the add-on might be invoking the Response constructor somewhere else and passing the response to where it's needed (e.g. as blob).

Flags: needinfo?(htsai)

Hi Gijs, thanks for bringing this up. I think Service Worker team would have a better view on this, so NI Andrew. :)

Hi Andrew, please let me know if there's anything my team can help with.

Flags: needinfo?(htsai) → needinfo?(overholt)

Perry, let's try to get this fixed as soon as parent intercept lands (or before?).

Assignee: nobody → perry
Flags: needinfo?(overholt)
Pushed by
Don't crash on `Response` constructor in WebExtensions. r=baku
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.