Enable ParentProcessDocumentChannel on all platforms
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: jya, Unassigned)
References
(Regression)
Details
(Keywords: regression)
I pushed the ParentProcessDocumentChannel (bug 1607984) behind a pref and disabled it following a rebase last week that changed some behaviours.
In particular this test is now failing:
https://searchfox.org/mozilla-central/source/toolkit/components/extensions/test/xpcshell/test_WebExtensionContentScript.js#204
There are several issues that prevented this problem to be quickly resolved.
In bug 1625513, the BrowsingContext object was made to implement nsILoadContext, unfortunately it doesn't implement QI for this interface.
Prior bug 1594529, the loading context given to the DocumentChannel object was the one provided by the doc shell.
The test now failing listens to http-on-examine-response, and caches the nsIChannel passed with it.
This would have been the inner nsHttpChannel within DocumentLoadListener, and that had the LoadInfo instantiated within DocumentLoadListener::Open
After bug 1594529, The DocumentLoadListener::Open creates from scratch that loadinfo.
the test code is calling into WebExtensionContentScript.h to extract a nsILoadContext from the LoadInfo
Previously we had a reference to the outer Element in the LoadInfo provided by PPDC, but now there are no references to things that aren't cross-process safe
The solution would be to not use the embedder Element to find an nsILoadContext but instead using the browsing context, which also implements nsILoadContext
This can be done by modifying https://searchfox.org/mozilla-central/rev/41c3ea3ee8eab9ce7b82932257cb80b703cbba67/toolkit/components/extensions/WebExtensionContentScript.h#72
DocInfo:: GetLoadContext() const
However, we need to be able to determine on which BC to return from that docinfo as it will depends on what is calling that method?
the outer window, the innerwindow, a sub-frame etc.
Comment 1•5 years ago
|
||
Reporter | ||
Comment 2•5 years ago
|
||
After talking to Matt, we found what caused to fail with browser/components/extensions/test/browser/browser_ext_webRequest.js
The analysis below is still correct and needs to be investigated. Will have another bug more explicit about it.
Updated•5 years ago
|
Description
•