Also removes some dead code.
A lot of the code in ExtensionUtils.jsm is not needed in all processes, and a
lot of the rest isn't needed until extension code runs. Most of it winds up
being loaded into all processes way earlier than necessary.
MozReview-Commit-ID: CMRjCPOjRF2
--HG--
extra : rebase_source : 37718eaf05a22b8ccb95f633cf7454bd7975cdce
Bill, can you please review the WebIDL change, and Shane the rest?
MozReview-Commit-ID: 6N3sGrAsHzs
--HG--
extra : rebase_source : adb925ec3dc2a350fc6f9d6cde7a3607f6877384
Bill, can you please review the binding code? Shane and zombie, can you please
review the content script matching?
MozReview-Commit-ID: IJB5s0a7r7S
--HG--
extra : rebase_source : 4026105b8c04e6b88c9be8cf76898fca26f1c3e0
This removes unnecessary COM overhead from the extension protocol service,
particularly from the flag lookup code, which is called often, and from hot
paths. The devirtualized lookups should have virtually no overhead for
extensions without web-accessible resources, and very little overhead except
when resources are specified as non-prefix globs.
MozReview-Commit-ID: 4hQ7GuQSjvW
--HG--
extra : rebase_source : 61897a204abd915ad61852fa475cde2de51753f3
This replaces the JS policy service stubs with a pure C++ version which
directly makes policy decisions based on active WebExtensionPolicy objects.
This is the first step in a larger refactoring, which will remove the
ExtensionManagement module entirely, and replace the current add-on policy
service with direct, non-virtual access to native WebExtensionPolicy objects.
It will also be followed by related changes to migrate the content script and
extension page matching to native code, based on the existing MatchPattern and
WebExtensionPolicy bindings.
MozReview-Commit-ID: 2MpbmXZGiPZ
--HG--
extra : rebase_source : 8b268618164b45605143e858665e592de829a6fa
Bill, can you please review the binding changes? Shane, can you please review
the policy service?
This is the first step to making extension policy data directly available to
C++ code without any COM overhead. It tracks the set of currently active
extensions, and how they map to add-on IDs and URIs.
MozReview-Commit-ID: 9Z61AXFll3P
--HG--
extra : rebase_source : c38898905a63ab8d0a424bfda7c61ea6c645ff32
Bill, can you please review the binding code and the general sanity of the
platform code? Andrew and zombie, can you please review the policy logic and
tests?
As in part 1, this aims to reduce the overhead of our extension policy logic
by making it directly available to native code with as little JS and XPConnect
overhead as possible.
MozReview-Commit-ID: 40m1wSEYtBo
--HG--
extra : rebase_source : c03834791707f78431440af9b88035ab03dc9564
This is the second step to migrating the policy service to pure native code,
with similar impacts and reasoning to the previous patch.
MozReview-Commit-ID: L5XdPzWNZXM
--HG--
extra : rebase_source : dda006a0afb9d56e2738dbc0b0d94ba0496db5c9
This is the first step toward migrating the web-accessible URL policy to
purely native code. It should have a noticeable performance improvement on its
own, but the main improvement comes from being able to pass the pattern
objects to the pure C++ policy service.
MozReview-Commit-ID: DHoGLVr8yJ9
--HG--
extra : rebase_source : 6f696bdea062bfd20fce33fe4e07b53a85b6e5d1
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
There are three flags in ProfileEntry::Flags, which suggests there are 2**3 = 8
combinations. But there are only actually 4 valid combinations.
This patch converts the three flags to a single "kind" enum, which makes things
clearer. Note also that the patch moves the condition at the start of
AddPseudoEntry() to its callsite, for consistency with the earlier JS_OSR entry
kind check.
--HG--
extra : rebase_source : 0950769ee1530291860ef3be47d240df5939e871
The category handling code at the end of AddPseudoEntry has two problems.
- The assertion checks |category| for the IS_CPP_ENTRY flag. This represents a
confusion between the entry's |category| and its |flags|. They're both stored
in a single uint32_t, but are conceptually different types. So the assertion
is vacuously satisfied.
Furthermore, there's no clear way to fix the assertion -- it doesn't make
sense to check the entry's flags for IS_CPP_ENTRY, because this code can
clearly take C++ or JS entries. So the patch just removes the assertion.
- The category is compared to zero. This also doesn't make sense, because zero
isn't a valid category. The patch removes this comparison.
--HG--
extra : rebase_source : 16a7248ffb90ccd90e6102d597fb5bdff706312e
If a frame doesn't have that bit then skip mCounterManager.DestroyNodesFor()
when the frame is destroyed because it's definitely not known by
the CounterManager.
MozReview-Commit-ID: Ky3575QvZME
