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 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
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
This allows native messaging binaries to identify the add-on that
invoked the native messaging app, in case more than one add-on is
allowed to launch the native messaging app.
MozReview-Commit-ID: GgjwfJDbBkW
--HG--
extra : rebase_source : b60d33e9f3936f26b8792ef5cd1f9fea304f29ae
Implement privacy.network.peerConnectionEnabled to allow WebExtensions to enable and disable RTCPeerConnections (aka WebRTC).
MozReview-Commit-ID: 5zGotQNwsko
--HG--
extra : rebase_source : 3543efa9fdbd7689581b3ffd3507cf2b4fee284d
Backed out changeset 916250167bc8
Backed out changeset c2a286511a6c
Backed out changeset 9cc319bef82d
Backed out changeset 29443725aebb
--HG--
extra : histedit_source : 76915ec4b96c97ee6bd4896769158490442aedce%2C0face0f9fe6eb85dd4ba8b3603bf948e0ce99d7f
This code seems to have never worked correctly. This code was based on
an error style that is thrown from one part of kinto-http.js but then
immediately rethrown using a different format. On top of that, the
code as written tries to parse JSON out of the response body and use
that. Instead, let's use the response status code, since that feels a
little more robust.
MozReview-Commit-ID: B5MG5tpduCd
--HG--
extra : rebase_source : 9f4ba94ef215297db6ba3b126852984a9a7878fe
This is another edge case that seems to be linked to the server-side
data loss bug in Kinto. It seems like you can get into a "server was
flushed" case if one device hadn't seen the most recent keyring before
another client caused the server to be wiped. We don't expect this to
happen in the future, but it affects some number of our users who were
already using storage.sync, so build a recovery pathway for them.
MozReview-Commit-ID: K0BJNQgN6Z4
--HG--
extra : rebase_source : 5a8707bc1edc1f30306a301d3c9f7b10a1f2fb76
This changes the behaviour of ExtensionSettingsStore so that attempting to remove a setting that was not previously set does
not throw an exception. This allows things like privacy.network.webRTCIPHandlingPolicy.clear() to be called without having
previously called privacy.network.webRTCIPHandlingPolicy.set().
MozReview-Commit-ID: FFCOFHk5lhb
--HG--
extra : rebase_source : a493b50145729a5388acbe1ace948f41de9762aa
Add WEBEXT_BACKGROUND_PAGE_LOAD_MS histogram that measures the time from
initiating the build() function to when the page is loaded.
MozReview-Commit-ID: 4duZuIlZnXk
--HG--
extra : rebase_source : eafd1f6228f69fa7eea4966af6151c2bc92aad06
