ExtensionPolicyService::CheckContentScripts does retrieve mContentScripts a WebExtensionPolicy instance
and it may call the ExtensionProcessScript methods PreloadContentScript or LoadContentScript while iterating
over it mContentScript.
Both PreloadContentScript and LoadContentScript are going to run some privileged JS code, and LoadContentScript
will load an extension content script. There is a chance that some of the JS code executed could call
WebExtensionPolicy::UnregisterContentScript (or RegisterContentScript) and mutate the mContentScripts array
that EPS::CheckContentScripts is already iterating over, and when that happens it is possible that once the
execution goes back to the ongoing CheckContentScripts iteration, the iterator is invalidated and
the InvalidArrayIndex_CRASH triggered.
Differential Revision: https://phabricator.services.mozilla.com/D69336
This patch adds support for including content_scripts CSP in the extensions
manifest, along with all interfaces necessary to access the CSP value. This does not
implement actual use of the CSP for content scripts.
Differential Revision: https://phabricator.services.mozilla.com/D46824
--HG--
extra : moz-landing-system : lando
The basic idea is to make non-initial about:blank fire
document-element-inserted notifications just like every other document. We
then ensure that there's a notification (initial-document-element-inserted)
that only gets fired once per window for documents that are in a window. This
notification is what webextensions use to inject into the document.
The old setup which injected into about:blank when its global is created gets
removed in favor of injecting the same way as into every other document.
The changes to Document.cpp are fixing a bug in the "block the parser" stuff
webextensions do. For about:blank, the blocking happens at a point when the
parser really has nothing else to parse (since it's parsing the empty string).
So the blocking is a no-op. But we do want to prevent DOMContentLoaded firing,
because otherwise the "end of document" scripts could run before we finish
doing the "beginning of document" work in webextensions. So we want to make
sure we block DOMContentLoaded, not just the load event.
Differential Revision: https://phabricator.services.mozilla.com/D19892
--HG--
extra : moz-landing-system : lando
The basic idea is to make non-initial about:blank fire
document-element-inserted notifications just like every other document. We
then ensure that there's a notification (initial-document-element-inserted)
that only gets fired once per window for documents that are in a window. This
notification is what webextensions use to inject into the document.
The old setup which injected into about:blank when its global is created gets
removed in favor of injecting the same way as into every other document.
The changes to Document.cpp are fixing a bug in the "block the parser" stuff
webextensions do. For about:blank, the blocking happens at a point when the
parser really has nothing else to parse (since it's parsing the empty string).
So the blocking is a no-op. But we do want to prevent DOMContentLoaded firing,
because otherwise the "end of document" scripts could run before we finish
doing the "beginning of document" work in webextensions. So we want to make
sure we block DOMContentLoaded, not just the load event.
Differential Revision: https://phabricator.services.mozilla.com/D19892
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Make the WindowProxyHolder hold a strong reference to a BrowsingContext, as in the future
we might not have a nsPIDOMWindowOuter (if the document is loaded in a different process).
Differential Revision: https://phabricator.services.mozilla.com/D12651
--HG--
extra : moz-landing-system : lando
This simplifies things all around, and gets rid of one more unnecessary
component registration.
--HG--
rename : toolkit/components/extensions/extension-process-script.js => toolkit/components/extensions/ExtensionProcessScript.jsm
extra : rebase_source : 7ceb6ada0730f8241bbd5ddbd889a320da22b1b1
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
The patch introduces NS_GetURIWithNewRef and NS_GetURIWithNewRef which perform the same function.
Differential Revision: https://phabricator.services.mozilla.com/D2239
--HG--
extra : moz-landing-system : lando
Going through the extension policy service rather than using
WebExtensionPolicy objects directly adds a lot of unnecessary overhead to
common operations on extension principals, and also makes the code more
complicated than it needs to be.
We also use weak references to policy objects here, since principals should
ideally lose as much of their elevated privileges as possible once the
extension instance that created them has been destroyed (which is something we
couldn't handle easily when we simply tracked ID strings).
MozReview-Commit-ID: KDNvVdvLkIt
--HG--
extra : rebase_source : 1b567919d2461bd0315d1a7d89f330cbd585f579
Bill, can you please review the WebIDL change, and Shane the rest?
MozReview-Commit-ID: 6N3sGrAsHzs
--HG--
extra : rebase_source : adb925ec3dc2a350fc6f9d6cde7a3607f6877384
