This tweak does also increase the space between messagebars (and between messagebars and list of extension) a little bit
compared to the 2px value used originally.
Depends on D228677
Differential Revision: https://phabricator.services.mozilla.com/D229617
This patch adds the USER_SCRIPT value as a supported value in the
internal WebExtensionContentScript constructor.
This patch does not introduce a distinct USER_SCRIPT sandbox yet; that
will be done in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D228973
- Add "userScripts" permission for MV3.
- Add "userScripts" namespace for MV3, and add schema and logic to make
sure that this namespace is limited to MV3 only.
- Add tests to verify that the "userScripts" namespace of MV2 and MV3
are completely isolated.
- The functionality in this patch is limited to verifying that the API
bindings and permission requirement works; the rest of the
implementation will follow in the next patches.
Depends on D223016
Differential Revision: https://phabricator.services.mozilla.com/D222492
Although the bindings generator skips MV2-only APIs at some point
(https://searchfox.org/mozilla-central/rev/1bc0601cc5b3d4c3919d220acbe248221ebce035/toolkit/components/extensions/webidl-api/GenerateWebIDLBindings.py#337-338),
that only happens after loading all schemas. Because user_scripts.json
contains multiple userScripts.register definitions (one for MV2 and one
for MV3), GenerateWebIDLBindings.py raised the following error before
this patch:
> TypeError: Unxpected multiple schema data for API property "userScripts.register" in schema group toolkit
This patch fixes the issue by ignoring the schemas that define the
userScripts API, and now the following test passes again:
```
./mach test toolkit/components/extensions/webidl-api/test/test_all_schemas_smoketest.py
```
Differential Revision: https://phabricator.services.mozilla.com/D227969
My initial version of my patch for part 1 didn't have a "nothing" comment
because I copied the empty loop from somewhere that didn't have it. If
the comment is appropriate, let's make things consistent while I'm
touching this file anyways.
Differential Revision: https://phabricator.services.mozilla.com/D229500
Changes in Bug 1131324 made it possible for
ServiceWorkerRegistration.showNotification to be invoked from Dedicated
and Shared Workers where previously it could only be invoked from
Service Workers. The fuzzer discovered this new possibility for which
we did not have test coverage for and revealed that the code would call
a WorkerPrivate method that required the global be a ServiceWorker which
causes a diagnostic assert or a release assert depending on the build
type.
It turns out the check in question was enforcing a constraint not
required by the spec that only the active worker associated with the
registration can cause a notification to be shown associated with the
registration. All that is required is that the registration have some
active worker.
When addressing this it also turned out that since the initial
implementation of the notifications API there has been an unneccessary
check that the principal associated with the global is same-origin to
the scope. This check additionally required a sync runnable to be
dispatched to the main thread. This check was unnecessary and has been
removed. All ServiceWorkerRegistrations exposed to a global are
inherently same-origin to the global and the check as implemented was
not aware of the effective storage principal and was just using the
(node) principal. (And any checks concerned about dealing with a rogue
content process would need to take place in the parent process, not the
potentially rogue content process.)
For testing, the recently updated test
`test_notification_serviceworker_show.html` has been forked to provide
dedicated worker coverage. If the test is run without the fix in this
patch applied, the expected assertion trips.
Differential Revision: https://phabricator.services.mozilla.com/D229561
browser_scroll_size_determination.js is occasionally leaking browser windows. My theory is that this
is happening because `BrowserTestUtils.overflowTabs` keeps them alive in order to reset the
scrollbox attribute that it changed and then there is not enough time after cleanup for the windows
to get fully collected. Given that these windows are closed anyway there is no need to actually do
this cleanup step so this allows us to skip it.
Differential Revision: https://phabricator.services.mozilla.com/D229587
