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
With this change, ext-webRequest.js will throw an ExtensionError when "blocking" is used without the "webRequestBlocking" permission, and ExtensionParent.jsm will relay that error to ExtensionChild.jsm so an error can be logged to the extension debugging console. Previously, the error was only being logged to the browser console.
Differential Revision: https://phabricator.services.mozilla.com/D9937
--HG--
extra : moz-landing-system : lando
Also, use a single hidden window to hold <browser> elements
for multiple extensions.
Differential Revision: https://phabricator.services.mozilla.com/D14163
--HG--
rename : browser/components/extensions/test/browser/browser_ext_tabs_cookieStoreId.js => browser/components/extensions/test/browser/browser_ext_tabs_cookieStoreId_private.js
extra : moz-landing-system : lando
This probably deserves a comment as of why it belongs to this bug.
This patch series caused a single, reproducible timeout on
browser_ext_themes_toolbars.js, where the transitionend event it awaits for
stops triggering.
I got fascinated by it and I decided to poke around it in rr instead of just
removing the await line, and here's what's going on.
In the previous implementation of _sanitizeCSSColor, we were not flushing style
because of the optimization bug 1363805 introduced (which wasn't supposed to
deal with out-of-document elements, but it accidentally did so).
In any case, the fact that we were not flushing style in _sanitizeCSSColor
caused us to flush style sometime later when the lwtheme attribute was already
set up, and thus the selector in here matched:
https://searchfox.org/mozilla-central/rev/cfaa5a1d48d6bc6552199e73004ecb05d0a9c921/browser/themes/shared/browser.inc.css#40
And thus caused the transition rule to apply at a time where the
background-color change happened.
Now we were flushing on getComputedStyle on every call, and in the most
inefficient way possible (changing a custom property on the root before each
property change, which causes us to restyle the whole document to propagate it
down to all descendants).
Furthermore, we were flushing style at a time where the lwtheme attribute
change had not yet happened, and thus when the background-color changed, there
was no transition rule applicable, and the transition didn't fire.
This patch changes LightweightThemeConsumer to avoid restyling the whole
document over and over.
Also, while at it I realized that you could fool the sanitizer with !important
in an experiment stylesheet or with other !important rule in the page really.
It's not clear why you'd do that, but it may be worth to just making that
function completely sound, so I did that and added a test for it.
Differential Revision: https://phabricator.services.mozilla.com/D13716
See D13472 for spec quotes and such. Other browsers don't allow
getting computed styles in disconnected subtrees and we agreed to follow suit
(it does make sense because when you're not on the flat tree it's not defined
what you're supposed to inherit from, specially in presence of Shadow DOM).
Also, it allows the style system to rely on the DOM being in a sane state.
Differential Revision: https://phabricator.services.mozilla.com/D13551
This probably deserves a comment as of why it belongs to this bug.
This patch series caused a single, reproducible timeout on
browser_ext_themes_toolbars.js, where the transitionend event it awaits for
stops triggering.
I got fascinated by it and I decided to poke around it in rr instead of just
removing the await line, and here's what's going on.
In the previous implementation of _sanitizeCSSColor, we were not flushing style
because of the optimization bug 1363805 introduced (which wasn't supposed to
deal with out-of-document elements, but it accidentally did so).
In any case, the fact that we were not flushing style in _sanitizeCSSColor
caused us to flush style sometime later when the lwtheme attribute was already
set up, and thus the selector in here matched:
https://searchfox.org/mozilla-central/rev/cfaa5a1d48d6bc6552199e73004ecb05d0a9c921/browser/themes/shared/browser.inc.css#40
And thus caused the transition rule to apply at a time where the
background-color change happened.
Now we were flushing on getComputedStyle on every call, and in the most
inefficient way possible (changing a custom property on the root before each
property change, which causes us to restyle the whole document to propagate it
down to all descendants).
Furthermore, we were flushing style at a time where the lwtheme attribute
change had not yet happened, and thus when the background-color changed, there
was no transition rule applicable, and the transition didn't fire.
This patch changes LightweightThemeConsumer to avoid restyling the whole
document over and over.
Also, while at it I realized that you could fool the sanitizer with !important
in an experiment stylesheet or with other !important rule in the page really.
It's not clear why you'd do that, but it may be worth to just making that
function completely sound, so I did that and added a test for it.
Differential Revision: https://phabricator.services.mozilla.com/D13716
See D13472 for spec quotes and such. Other browsers don't allow
getting computed styles in disconnected subtrees and we agreed to follow suit
(it does make sense because when you're not on the flat tree it's not defined
what you're supposed to inherit from, specially in presence of Shadow DOM).
Also, it allows the style system to rely on the DOM being in a sane state.
Differential Revision: https://phabricator.services.mozilla.com/D13551
Updated the totalBytesGreater property in browser.downloads.search({}) to default to -1 so files with a byte size of 0 will be returned.
Differential Revision: https://phabricator.services.mozilla.com/D12344
--HG--
extra : moz-landing-system : lando
With this change, ext-webRequest.js will throw an ExtensionError when "blocking" is used without the "webRequestBlocking" permission, and ExtensionParent.jsm will relay that error to ExtensionChild.jsm so an error can be logged to the extension debugging console. Previously, the error was only being logged to the browser console.
Differential Revision: https://phabricator.services.mozilla.com/D9937
--HG--
extra : moz-landing-system : lando
This patch replace the LWT aliases with their related non-deprecated alias in all the theme API tests
that don't seem to be specifically testing the LWT aliases (e.g. browser_ext_themes_lwtsupport.js is
leaved unmodified for this reason).
The main reason to replace them in the "not stricly LWT-related" tests before their final removal
(currently planned for Firefox 69) is that the deprecation warnings will make these tests more
noisy (and so they may be making harder to investigate failures, without any actual gain in terms
of coverage).
Depends on D12297
Differential Revision: https://phabricator.services.mozilla.com/D12783
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
In Bug 1479125 we put calls to .children that were intended to access child elements into the custom
method, which is a slower path. We may eventually want to remove itemChildren altogether and just assume
that all children are items, but that's out of scope for a perf fix like this.
Differential Revision: https://phabricator.services.mozilla.com/D10751
--HG--
extra : moz-landing-system : lando
Bug 1344926 integrated static themes more closely into the existing infra-
structure for lightweight themes and also intended the static theme's image data
to be persisted to disk as well.
While the headerURL image file is in fact successfully copied out of the
extension archive into the profile, the persist progress listener being used
isn't equipped to properly handle this case and therefore the success callback
is never executed.
As a result
- the callback passed to _persistImages in the LWTManager isn't executed,
either, although because setting the fallbackThemeData passes in an empty
callback anyway, no one noticed.
- the persist operation never actually completes, so subsequent calls to
currentThemeForDisplay() always return the original moz-extension:// image URI
and never the persisted file from the profile folder.
For Android we definitively require a working callback in order to be able to
forward the fixed-up theme data once the image data has been persisted, so the
persistProgressListener's logic is modified accordingly.
Additionally, because as far as the LWTManager is concerned, WE static themes
are only fallback themes and a call to LWTManager.currentTheme will therefore
never return a WE static theme, the LWTPersister's logic to check whether the
theme, whose files have just been successfully persisted, is still the current
theme, needs to be modified.
Differential Revision: https://phabricator.services.mozilla.com/D10729
--HG--
extra : source : 91b2a9224846ef9cc81f1afc9fcfcd1db278644b
extra : histedit_source : d8a47bba3563cb8eb0faf94a7c1f28ba2925d80c
This patch solves half of the problem but it will still show the transition when the window regains focus. I am OK with removing the transition on the title bar, we will still have it on the navbar and bookmarks toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D11282
--HG--
extra : moz-landing-system : lando
If no handlers exist for a protocol, dont show the handler chooser dialog.
If a default handler exists, force showing the dialog when a new handler
has been installed so the user may choose the new handler.
Differential Revision: https://phabricator.services.mozilla.com/D10737
--HG--
extra : moz-landing-system : lando
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
This also adds new test coverage for the previously untested features:
- "file" in "js" param to userScripts.register works.
- "allFrames" set to true in userScripts.register works.
- scriptMetadata accepts primitive values, and in particular falsey
values in particular (= bug 1491397 ).
- scriptMetadata is the same object in all API script calls.
Differential Revision: https://phabricator.services.mozilla.com/D8582
--HG--
extra : moz-landing-system : lando
Bug 1478694 - Ensure that WebExtensions alarms set in the past are fired immediately.
Differential Revision: https://phabricator.services.mozilla.com/D7287
--HG--
extra : moz-landing-system : lando
Some oauth services require the redirect uri be configured on their service,
and the reject the redirect_uri param if we send it. Chrome works fine in this scenario,
but we have been requiring the redirect_uri be provided. This addresses that requirement
by using our own default redirect url, which would be the url used to configure the
oauth service.
Differential Revision: https://phabricator.services.mozilla.com/D6945
--HG--
extra : moz-landing-system : lando
The new permission is added to make it easier to audit the usage of the
API. It is an optional permission, in case we ever decide to introduce
a permission warning for it.
Differential Revision: https://phabricator.services.mozilla.com/D6771
--HG--
extra : moz-landing-system : lando
- Added definitions for the new telemetry events
- Send telemetry events for each AddonManager action on an extension.
- Ensure that telemetry events are sent also for the extension prompts.
Differential Revision: https://phabricator.services.mozilla.com/D4448
--HG--
extra : moz-landing-system : lando
The performance counter is now also used in the children, and
the ParentAPIManager.retrievePerformanceCounters() can be used
to aggregate all counters into a promise.
Differential Revision: https://phabricator.services.mozilla.com/D5399
--HG--
extra : moz-landing-system : lando
This patch introduces the userScripts API namespace and the userScripts.register API method,
which allows an extension to register some javascript code to run on the matched webpages
into an isolated sandbox (whereas all the content scripts from the same extension run in
a per-window sandbox shared by all the extension content scripts).
Differential Revision: https://phabricator.services.mozilla.com/D4353
--HG--
extra : moz-landing-system : lando
This patch introduces the userScripts API namespace and the userScripts.register API method,
which allows an extension to register some javascript code to run on the matched webpages
into an isolated sandbox (whereas all the content scripts from the same extension run in
a per-window sandbox shared by all the extension content scripts).
Differential Revision: https://phabricator.services.mozilla.com/D4353
--HG--
extra : moz-landing-system : lando
This patch moves the ExtensionTelemetry helpers (added into ExtensionUtils.jsm by Bug 1483002)
into a new ExtensionTelemetry.jsm and makes the ExtensionTelemetry a lazy getter on every one
of the JSM and API modules that are going to use it, so that we don't have to load these helpers
until they are actually used and we can reduce their impact on the base content memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D5266
--HG--
extra : moz-landing-system : lando
Fixes bug 1488105 and adds two new test files:
- browser test to test ping-pong from background page, sidebar and browserAction.
- xpcshell test with same test logic, mainly for Android test coverage.
The test uses uses contentScripts.register instead of the manifest
file to also have test coverage for contentScripts.register + child
frames in the background page.
These tests serve as a regression test for bug 1488105 and bug 1463074.
Differential Revision: https://phabricator.services.mozilla.com/D5261
--HG--
extra : moz-landing-system : lando
The original test_ext_alarms_replaces test was sensitive to system loads
that slowed down the execution of the test, resulting in intermittent
failures.
This new test tests the equivalent behavior (namely that calling
browser.alarms.create replaces a previous alarm), without being
sensitive to system load. This is achieved by creating a repeating alarm
and immediately replacing this alarm with a one-shot alarm that runs
later than the original alarm.
Differential Revision: https://phabricator.services.mozilla.com/D4698
--HG--
extra : moz-landing-system : lando
The original test_ext_alarms_replaces test was sensitive to system loads
that slowed down the execution of the test, resulting in intermittent
failures.
This new test tests the equivalent behavior (namely that calling
browser.alarms.create replaces a previous alarm), without being
sensitive to system load. This is achieved by creating a repeating alarm
and immediately replacing this alarm with a one-shot alarm that runs
later than the original alarm.
Differential Revision: https://phabricator.services.mozilla.com/D4698
--HG--
extra : moz-landing-system : lando
This patch contains a set of changes needed to add WEBEXT telemetry probes keyed by addon id.
The telemetry probes keyed by addon id has been added as separate telemetry histograms
named after the related generic WEBEXT probe with the additional "_BY_ADDONID" suffix.
A set of small helper methods have been defined in a new ExtensionTelemetry object, exported
by the ExtensionUtils.jsm.
Differential Revision: https://phabricator.services.mozilla.com/D4437
--HG--
extra : moz-landing-system : lando
- Register pagehide/pageshow events in the system group and ignore
synthetic events to avoid interference from web pages.
- Remove unused docShell member.
- Fix memory leak in bfcached windows, by ensuring that BaseContext
instances can be GC'd when an extension is unloaded, even if the
context is associated with a page in the bfcache.
- Ensure that context.contentWindow and context.active always have an
accurate value.
The latter is achieved by moving all contentWindow tracking logic in a
new helper class "InnerWindowReference".
Differential Revision: https://phabricator.services.mozilla.com/D4072
--HG--
extra : moz-landing-system : lando
- Register pagehide/pageshow events in the system group and ignore
synthetic events to avoid interference from web pages.
- Remove unused docShell member.
- Fix memory leak in bfcached windows, by ensuring that BaseContext
instances can be GC'd when an extension is unloaded, even if the
context is associated with a page in the bfcache.
- Ensure that context.contentWindow and context.active always have an
accurate value.
The latter is achieved by moving all contentWindow tracking logic in a
new helper class "InnerWindowReference".
Differential Revision: https://phabricator.services.mozilla.com/D4072
--HG--
extra : moz-landing-system : lando
- Register pagehide/pageshow events in the system group and ignore
synthetic events to avoid interference from web pages.
- Remove unused docShell member.
- Fix memory leak in bfcached windows, by ensuring that BaseContext
instances can be GC'd when an extension is unloaded, even if the
context is associated with a page in the bfcache.
- Ensure that context.contentWindow and context.active always have an
accurate value.
The latter is achieved by moving all contentWindow tracking logic in a
new helper class "InnerWindowReference".
Differential Revision: https://phabricator.services.mozilla.com/D4072
--HG--
extra : moz-landing-system : lando
These continue to run on Android/opt and on debug on other platforms. These tests
have very-long run times on Android/debug, making it impossible to balance chunk
run-times and causing intermittent task timeouts.
We've introduced a new pref network.cookie.quotaPerHost and also a rule that the value of network.cookie.maxPerHost should always be bigger than network.cookie.quotaPerHost. So, before changing the value of network.cookie.maxPerHost, we have to set network.cookie.quotaPerHost first.
This patch only sets network.cookie.quotaPerHost equal to network.cookie.maxPerHost - 1 in all failed tests.
Differential Revision: https://phabricator.services.mozilla.com/D4346
--HG--
extra : moz-landing-system : lando
The failure from the bug could happen if the test runs so slow that the
timer expires before the existence of the alarm is checked.
To avoid that failure, extend the lifetime of the alarm from 2 to 2000
seconds.
Differential Revision: https://phabricator.services.mozilla.com/D4678
--HG--
extra : moz-landing-system : lando
When `document.blockParsing()` is called, the nsIParser is suspended
until the document is unblocked. For about:blank documents, this is a
nsParser.
When a document is unblocked, nsParser::ContinueInterruptedParsingAsync
is invoked, which delegates its implementation to nsIContentSink, which
is a nsHTMLContentSink for about:blank documents. Due to a missing
implementation of nsHTMLContentSink::ContinueInterruptedParsingAsync,
the parser was never resumed, causing bug 1465388 and bug 1407501.
This patch fixes the problem, by implementing the required method (and
using a load blocker to ensure that the (about:blank) document does not
finish before the parser finishes).
This patch is tested through extension tests: Currently document_start
stylesheets always activate the parser blocker, and document_start
scripts trigger the parser blocker when the script has not been
preloaded yet (e.g. at the first run).
Before this patch, the test failed due to the assertion failure as
reported in the linked bugs. After this patch, the tests pass.
Differential Revision: https://phabricator.services.mozilla.com/D4352
--HG--
extra : moz-landing-system : lando
When `document.blockParsing()` is called, the nsIParser is suspended
until the document is unblocked. For about:blank documents, this is a
nsParser.
When a document is unblocked, nsParser::ContinueInterruptedParsingAsync
is invoked, which delegates its implementation to nsIContentSink, which
is a nsHTMLContentSink for about:blank documents. Due to a missing
implementation of nsHTMLContentSink::ContinueInterruptedParsingAsync,
the parser was never resumed, causing bug 1465388 and bug 1407501.
This patch fixes the problem, by implementing the required method (and
using a load blocker to ensure that the (about:blank) document does not
finish before the parser finishes).
This patch is tested through extension tests: Currently document_start
stylesheets always activate the parser blocker, and document_start
scripts trigger the parser blocker when the script has not been
preloaded yet (e.g. at the first run).
Before this patch, the test failed due to the assertion failure as
reported in the linked bugs. After this patch, the tests pass.
Differential Revision: https://phabricator.services.mozilla.com/D4352
--HG--
extra : moz-landing-system : lando
This makes it much easier to update existing consumers of
XPCOMUtils.enumerateCategoryEntries to use the category manager directly.
It also, unfortunately, requires updating existing category manager consumers
to use the Services getter in order to avoid ESLint errors.
Differential Revision: https://phabricator.services.mozilla.com/D4278
--HG--
extra : rebase_source : fb9fd9b21db80af472ff6250a2e9a35e8d538147
I've been unable to reproduce this intermittent locally (even by creating a
"win64 ccov debug" build on Windows 10), but it has been easy enough to trigger
on try.
The failure is triggered when the test has been completed and it is unloading the test extension1,
by the `NS_ERROR_FILE_ACCESS_DENIED` error raised from Extension's `cleanupGeneratedFile`
(https://searchfox.org/mozilla-central/rev/f2ac80ab7dbde5400a3400d463e07331194dec94/toolkit/components/extensions/Extension.jsm#1835-1841).
By comparing the test behavior when it runs successfully locally and fails on try, I've been
finally able to identify what goes wrong when it fails:
The reason for the `NS_ERROR_FILE_ACCESS_DENIED` is the ScriptCache entry for the
test extension1's content script, which is created when we create and load the
test content page which triggers it, this script cache entry should be cleared
when the extension shutdown (and it is cleared when the test runs successfully)
Then, right after the content script is executed, the contentPage is closed and this
is where something goes (intermittently) wrong with the ipc (and the following pipe errors
may be related to it: https://treeherder.mozilla.org/logviewer.html#?job_id=194750915&repo=mozilla-central&lineNumber=2692-2702) and, because of that, during the extension shutdown the "Extension:Shutdown" message broadcasted
to all the process never reaches the process where the content script cache entry has been
created (as well as "Extension:FlushJarCache" message sent to ensure that the jar cache is flushed
in every process), and so the XPI file is still kept active by that process and so it fails to be
removed on windows (where the usual `NS_ERROR_FILE_ACCESS_DENIED` is raised in this kind of scenarios).
The underlying issue doesn't seem to be strictly related to the behavior that this test file is
verifying (that is "checking that the expected telemetry data is being collected when the storage
APIs are being used"), and so I think that it would be reasonable to prevent the intermittent
by fixing the test (and closing the page after we unload the test extension 1 is enough to ensure
that the script cache entry is always cleared as expected and the file can be removed successfully
when the test is exiting).
The following push to try seems to confirm it (the oranges are triggered by another unrelated test
which fails intermittently in win64 ccov builds):
- https://treeherder.mozilla.org/#/jobs?repo=try&revision=978e21c57ef084c4115703bf827306320e81bcad
Differential Revision: https://phabricator.services.mozilla.com/D4067
--HG--
extra : moz-landing-system : lando
Creating non-shared scopes for frame scripts is fairly expensive. After these
changes it's even more expensive. However, many frame scripts have no use for
the shared scopes at all. Run-once scripts which execute in closures, for
instance, make no use of them. And after bug 1472491, neither do most of our
default frame scripts.
MozReview-Commit-ID: 9PK7bYdQ0yh
--HG--
extra : rebase_source : db2516d2f00a75e233e1957649f2b62a9299b7cd
This failure starts showing up after these changes by chance. Some aspect of
the environment or other causes a map() call to be baseline-optimized, which
causes its IC stubs to hold its function environemnt alive, which causes it to
hold the context we're checking alive.
Forcing a shrinking GC makes the IC stub go away sooner, and therefore allows
the test to pass.
MozReview-Commit-ID: LXp5mgMZeB1
--HG--
extra : rebase_source : 083c5425e55fcd512bda016c6aa2fb0d72ded7d9
A lot of the ad-hoc frame scripts we execute for tests does not run in strict
mode, and therefore has its functions' `this` objects set to the global when
they are called without a target object.
At the moment, this gives them a MessageManager global. Once message managers
become non-global objects, however, it will give them the shared JSM global,
which is not what they expect.
This patches changes scripts which rely on this to explicitly capture or set
the appropriate `this` object for their calls.
MozReview-Commit-ID: DY8DDb0xE1K
--HG--
extra : rebase_source : 86c1fa4df070711f666dfee5487182afe28a7611
This patch contains a small fix needed to fix an Android-only failure related to the test
test_ext_storage_idb_data_migration.js when running on a non-Nightly build.
After digging into it a bit I notice that the reason behind this failure is similar to
the one we fixed an year ago in Bug 1380287 for another test telemetry-related.
Differential Revision: https://phabricator.services.mozilla.com/D2952
--HG--
extra : moz-landing-system : lando
I found these schemes by enumerating all registered nsIProtocolHandler
and checking whether they require a "//".
The list of schemes in HOST_LOCATOR_SCHEMES only includes schemes that
are known to Firefox. Any other scheme is parsed as if the separator is
":". For example, NetUtil.newURI("unknown-scheme://host/path") has its
pathQueryRef member set to "//host/path". For the purpose of matching in
MatchPattern, this unknown scheme has therefore no host and only a path.
MozReview-Commit-ID: KGNRXGcZTZx
--HG--
extra : rebase_source : 2aece6a9d3e67d28567352e3bc3ed934f7f9a1d5
Otherwise MatchPattern::Matches would always return false if the
aExplicit flag is set to true, even if the match pattern is identical to
the tested URL.
MozReview-Commit-ID: FtdOgwrAkk8
--HG--
extra : rebase_source : 75fc36b176d59dba7556843686b04e5d50ab263f
The "data:" scheme is not followed by "//host". This patch fixes
the parser so that "data:..." is expected instead of "data://...".
MozReview-Commit-ID: 8TLVF3hdQ7H
--HG--
extra : rebase_source : 70fff5091c860bfdf2b727c4ff3ab08866b88efe
When the storage.local.get API method is called with a string parameter, it should return
a result object that only include that property (if it is one of the key stored into the
storage.local data backend).
This patch fixes the behavior of the ExtensionStorageIDB in the above scenario, and also
applies some related small changes to the tests (to add some additional assertion to verify
this behavior as part of the automated tests and to fix a mistake on a storage.local.get
call in one of the test case, which has been caught once fixed the storage.local.get behavior
for the string parameter).
Differential Revision: https://phabricator.services.mozilla.com/D2934
--HG--
extra : moz-landing-system : lando
Proxies must work with all requests, however the new onRequest proxy api
has maching logic using ChannelWrapper which uses WebExtensionPolicy which
checks against restricted domains. We need to bypass that check when
matching for proxy requests.
MozReview-Commit-ID: 5zCdmV1b9M7
--HG--
extra : rebase_source : 4bc0f2735a8c2cc4f42934877783dbc68f6067ab
And re-enable the test_ext_all_apis.html test to ensure that new APIs
are only available by default if the contributor really intents to.
MozReview-Commit-ID: FWIKybrk0EE
--HG--
extra : rebase_source : 58c5bd98ddb59be74b9454995cbbd3edef6c45f9
Adds a performance counter in ParentAPIManager to track the
number and duration of API calls by webextensions.
MozReview-Commit-ID: PTpaSCkE6A
--HG--
extra : rebase_source : 21c6c7f2e38c8808771fe4fea90d2750196202bd
