Closed Bug 1426562 Opened 2 years ago Closed 7 months ago

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

Categories

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

57 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox-esr60 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: speed, Assigned: perry)

References

(Blocks 1 open bug)

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(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
Status: UNCONFIRMED → NEW
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 testcase.zip
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 https://crash-stats.mozilla.com/report/index/42565032-450b-4f76-ad82-cfd2b0190425 we're hitting this release assert: https://searchfox.org/mozilla-central/rev/d143f8ce30d1bcfee7a1227c27bf876a85f8cede/dom/fetch/ChannelInfo.cpp#50-51

Which seems to suggest this codepath should only be usable from browser/Firefox code, not from add-ons. See also https://searchfox.org/mozilla-central/rev/d143f8ce30d1bcfee7a1227c27bf876a85f8cede/dom/fetch/Response.cpp#200-214 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 pjiang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/dac784d695b3
Don't crash on `Response` constructor in WebExtensions. r=baku
Status: NEW → RESOLVED
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.