Closed Bug 1426562 Opened 7 years ago Closed 6 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Version:
57 Branch
Type:
defect

Tracking

()

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

People

(Reporter: speed, Assigned: perry)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files)

testcase.zip
(deleted), application/x-zip-compressed
Details
Bug 1426562 - Don't crash on `Response` constructor in WebExtensions. r?baku
(deleted), text/x-phabricator-request
Details
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 (deleted) —
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
Blocks: ServiceWorkers-stability
Priority: -- → P2
This still crashes periodically in Fennec, but usually it is a single installation crash.
Component: DOM → DOM: Core & HTML

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

https://hg.mozilla.org/mozilla-central/rev/dac784d695b3

Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox68: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: