The intermittent failure triggered by this test is due to use of the wrong type signature for the AddonTestUtils.checkMessages
`forbidden` option, which expects the regular expression to be set as the value of the console message property that should be
checked against the regular expression.
Differential Revision: https://phabricator.services.mozilla.com/D146935
This introduces a breaking change: the buckets cannot be changed via preferences anymore.
Before landing this patch, we should have a released a new version of the Remote Settings DevTools that is compatible with this new API.
Differential Revision: https://phabricator.services.mozilla.com/D145455
This patch includes only the subset of D145687 changes related to the reworked JSONSchema data, plus some minor changes to Schemas.jsm to take the new
JSONSchema type ("PrivilegedPermissions") and the new custom JSONSchema keyword (the boolean "privileged" property used to identify manifest fields
only allowed in privileged extensions).
Besides the changes to the schema data, this patch is not expected to introduce any difference in behavior and so it could also land on its own
if needed (and the rest of the changes landed separately).
Differential Revision: https://phabricator.services.mozilla.com/D146800
This patch is making sure that `context.active` is going to be `false` when an extension page
has been moved into the bfcache because the `browser` element where it was loading into has been navigated
to a page that needs to run in a different process.
This also match the expected behavior for a same process navigation (e.g. an extension page being navigated
to another extension page) and the changes in this patch do also fix Bug 1499129 which was already happening
for same process navigations (and it does the same also for an extension page moved to the bfcache because
of a cross-process navigation case tracked by this bug).
The test case included in this patch cover both same-process and cross-process navigations under fission
and non fissions jobs.
Differential Revision: https://phabricator.services.mozilla.com/D145919
This patch includes only the subset of D145687 changes related to the reworked JSONSchema data, plus some minor changes to Schemas.jsm to take the new
JSONSchema type ("PrivilegedPermissions") and the new custom JSONSchema keyword (the boolean "privileged" property used to identify manifest fields
only allowed in privileged extensions).
Besides the changes to the schema data, this patch is not expected to introduce any difference in behavior and so it could also land on its own
if needed (and the rest of the changes landed separately).
Differential Revision: https://phabricator.services.mozilla.com/D146800
List of changes:
- renamed a section for clarity (WebExtensions Experiments -> Adding
Experimental APIs in Privileged Extensions)
- fixed a few typos because I think we should consistently use the name
WebExtensions (with a `s`) when it is followed by API(s) at least
- added a link to the xpi-manifest repo in a notice (main repo, not the
`docs/` folder or a markdown file because that may change)
- Experimental APIs is referenced in the section that has been edited so
made it clear what is an Experimental API vs Built-in (hopefully).
Also kept the reference to "WebExtensions Experiment" (which seems to
be an alias)
Differential Revision: https://phabricator.services.mozilla.com/D146537
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
The deserialize parameter is used only for getting global object, and in the JSM
context, it's the shared global. So directly passing globalThis works.
Differential Revision: https://phabricator.services.mozilla.com/D144133
The test failing intermittently on test-verify jobs seems to be only the one that covers the newly added
Glean timespan metric named "extensions.startupCacheLoadTime".
Given that it seems to be only failing in test-verify jobs, and with the Glean metric set to a numeric value as expected
just not always a non-zero value as the test expectes, I suspect it may be because the startupCache is technically
empty or only including a pretty small amount data and so it may be able to be loaded so fast that the resulting
value is 0 milliseconds.
I'm unable to reproduce the same locally even when running the test locally using --verify, and so this patch
is actually relaxing the failing assertion to only check that the Glean metric value is numeric and the
mirror scalar is set to the exact same value, and in addition to that the test is not reseting the FOG data
and assert that the Glean metric is initially undefined until we expect it to be collected and set to a numeric value.
Differential Revision: https://phabricator.services.mozilla.com/D145904
The test failing intermittently on test-verify jobs seems to be only the one that covers the newly added
Glean timespan metric named "extensions.startupCacheLoadTime".
Given that it seems to be only failing in test-verify jobs, and with the Glean metric set to a numeric value as expected
just not always a non-zero value as the test expectes, I suspect it may be because the startupCache is technically
empty or only including a pretty small amount data and so it may be able to be loaded so fast that the resulting
value is 0 milliseconds.
I'm unable to reproduce the same locally even when running the test locally using --verify, and so this patch
is actually relaxing the failing assertion to only check that the Glean metric value is numeric and the
mirror scalar is set to the exact same value, and in addition to that the test is not reseting the FOG data
and assert that the Glean metric is initially undefined until we expect it to be collected and set to a numeric value.
Differential Revision: https://phabricator.services.mozilla.com/D145904
I chose to write a minimal test case and defer more test coverage to Bug
1723763 since this bug already existed. The change in `ext-android.json`
is similar to what has been done in D113461.
Differential Revision: https://phabricator.services.mozilla.com/D146061
The failures are triggered by the pending request used by the initial four test cases, due to the pending request
being aborted (after all the tests in the test file have been executed and the test harness executes all the
registered cleanup functions) and its related promise rejection not being caught by the test itself.
Apparently the failures seems to be able to be triggered more often on windows builds, but I have been able to trigger it
on Linux using --verify even if way less often then on Windows (where I was able to trigger the failures consistently
by running the test file once and without --verify).
The attached patch prevents the failure by explicitly:
- handling the promise rejection (by catching the rejection, emit a log if the rejection is the expected one and
trigger an explicit failure nearby where it is triggered otherwise, to make it easier to investigate other issues
in the future if needed, by prevent the rejection to become silent and by triggering a failure easier to be
correlated with what is actually triggering it)
- clearing the last pending request created right at the end of the test task that has created it (mainly to avoid
keeping the request active if the related test is already exiting)
Differential Revision: https://phabricator.services.mozilla.com/D145958
mochitest and web-platform-test are verifying import maps are supported.
xpcshell-test is used to verify import maps are _NOT_ supported for web ext
content scripts.
Differential Revision: https://phabricator.services.mozilla.com/D142077
mochitest and web-platform-test are verifying import maps are supported.
xpcshell-test is used to verify import maps are _NOT_ supported for web ext
content scripts.
Differential Revision: https://phabricator.services.mozilla.com/D142077
The general idea is that when extensions are installed at startup, they request permissions needed. Some examples of permissions might be access to downloads or bookmarks. This patch implements the ability to request permissions after install during runtime. A common optional permission is geolocation. The app won't request the user's location until needed.
GeckoView will provide a delegate to apps called onOptionalPrompt that provides the extension and the permissions the extension is requesting. They can then query the user to accept or reject the permission. The delegate works by listening to the browser API browser.permissions.request. Any browser API will be linked to a corresponding file and function such as ext-permissions.js::request() in this example. request() notifies observers of the topic webextension-optional-permission-prompt. ExtensionPromptObserver listens to that topic and dispatches an event GeckoView:WebExtension:OptionalPrompt. The geckoview web extension controller listens on that event and pass the extension and permissions to the skeleton delegate functions, that will get implemented by the app.
To verify this works, the test case WebExtensionTest.kt installs an extension through the package xpi. The package is created on build from moz.build to contain the extension's manifest.json and necessary scripts. Once the extension package is installed, we load the html script in the package that states when the page is clicked, trigger the browser API browser.permissions.request. The click is simulated with synthesizeTap. This request is then observed by listeners like mentioned in the previous paragraph. We verify in our skeleton delegate that the permissions provided match the ones requested.
Differential Revision: https://phabricator.services.mozilla.com/D143925
Initially, I thought the bug was related to a missing `extension.id` in
`ExtensionProcessScript.jsm` [1] but that isn't always reproducible.
There is possibly an issue there but I don't think it is the root cause
of the intermittent here (I would think that other OSes would be affected,
which isn't the case according to [2]).
@rpl and I investigated and we noticed that the mochitest error reported
didn't contain a meaningful error:
```
[object Object] - Should not throw any errors
```
Once we fixed the test framework output, we got:
```
FAIL {"operation":"remove","path":"C:\\Users\\William\\AppData\\Local\\Temp\\generated-extension-23.xpi","winLastError":5,"stack":"","fileName":"(unknown module)"} - Should not throw any errors
```
This is why this patch attempts to fix the intermittent by unloading the
extensions first and then removing the tab. As @rpl said:
> That may actually make sense, maybe removing the tab right before the
> unload prevented the extension to coordinate with the child process and
> make sure we flushed the cache, and that process may not have been yet
> fully destroyed.
[1]: https://searchfox.org/mozilla-central/rev/ecd91b104714a8b2584a4c03175be50ccb3a7c67/toolkit/components/extensions/ExtensionProcessScript.jsm#124
[2]: https://treeherder.mozilla.org/intermittent-failures/bugdetails?startday=2022-04-22&endday=2022-04-29&tree=trunk&bug=1761550
Differential Revision: https://phabricator.services.mozilla.com/D145104
This patch ensures that fetch/XHR from MV3 content scripts have the
same capabilities as the web page, by relying on the fetch/XHR methods
inherit from the window prototype that use the page's principal, instead
of overwriting them with methods that use the expanded principal (MV2).
For completeness, although the WebSocket constructor does not require
origin permissions, I have also removed the similar special hack for
WebSocket, so that its behavior is also consistent with the page.
It is worth noting that currently, the page's CSP affects these methods,
instead of the content script's CSP (bug 1766813).
Besides the fix, this patch has test changes:
- test_ext_contentscript_csp.js was modified, to remove MV3 tests that
rely on content.fetch and content.WebSocket, since the "content"
global has been removed with the unification of these methods in
content scripts. Two test expectations were changed to account for
the CSP enforcement regression (bug 1766813).
- test_ext_contentscript_json_api.js was added because there is no
specific coverage for the use of JSON APIs in content scripts, despite
special handling in the code touched by this patch (from bug 1284020).
I have also added a comment to the implementation to explain why the
special handling was/is needed (this behavior remains unchanged).
- test_ext_secfetch.js was modified to test the fetch behavior of MV3.
A previously-commented out test (fetch with CORS) was enabled since
that behavior was resolved in MV3, and the (still failing) MV2 test
results are annotated with the current failure (due to bug 1605197).
- test_ext_webSocket.js was modified to test the WebSocket behavior of
MV3. Since this patch doesn't change the behavior for moz-extension:
documents, the iframe tests are not affected by the fix. New
content scripts-specific tests were introduced, along with test
expectations for MV2 (unchanged) and MV3 (changed by this patch).
- test_ext_xhr_cors.js was introduced to test various scenarios with
using XHR from MV3 content scripts. MV2 test coverage was not strictly
required because it was mostly covered by test_ext_permission_xhr.js,
but included for comparison. There is new test coverage for requests
with CORS (which was/is still failing in MV2 - bug 1605197).
Differential Revision: https://phabricator.services.mozilla.com/D144931
