This applies to when the user is on the home screen and the navbar is shown.
Currently in most situations we hide the home screen toolbar (addressbar + navbar) too early
and so for a split second there is no toolbar on the screen until the one for search is shown.
Moved to use the result listener framework which in tests is much faster than relying on store
updates to know if search is visible or not (instant vs ~60ms on a Pixel 6) which allows with
greater reliability to transition between the toolbar from the home screen and the toolbar
from the search screen.
Differential Revision: https://phabricator.services.mozilla.com/D228180
This applies to when we navigate to the homescreen which initializes it's navbar and then
immediately opens the search dialog.
Previously we would hide the entire bottom toolbar (addressbar + navbar) which could lead
to situations in which there is no toolbar shown on the screen until the one from search
is visible.
Differential Revision: https://phabricator.services.mozilla.com/D228179
Also solve a related layout race with the find in page bar first appearing with a 0 height
and saving it as an anchor but for later layout changes we would not reposition the download
panel since in the meantime the height was updated to a bigger value and we'd assume this
bigger value was already used to position the download panel.
Now we'll ignore remembering an anchor if it's not visible or has a 0 height which will
allow to react more reliably to layout changes.
Differential Revision: https://phabricator.services.mozilla.com/D228968
There is a race between responding to layout changes and animating the download complete panel.
With the navbar enabled when changing device orientation the bottom toolbar cycles through
no toolbar, just the address bar, addressbar + navbar.
If the animation to show the panel starts while the toolbar layout is still updated then it
will set a wrong translationY for placing the download complete panel above the toolbar.
If the animation ends after the layout has settled then we will not update the anchor and the
right translationY again since other code this has already been set.
To overcome all this when the animation ends we will set the current toolbar height as the
translationY value need to correctly place the download complete panel above the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D228967
Currently lacking ARM coverage for the jetstream2 test, so this patch
enables it on the apple silicon and android A55 device.
Differential Revision: https://phabricator.services.mozilla.com/D228239
When a Worker starts shutdown, RemoteWorkerNonLifeCycleOpControllerChild will call SendTerminated() to the parent side to nullify the RemoteWorkerController::mNonLifeCycleOpController to forbidden message sending from RemoteWorkerController.
However, SendTermainted() does not close the IPC channel, this causes the channel still can send/receive messages from IPC internal mechanism.
This patch force to close the IPC channel when Shutdown/Terminated send.
Differential Revision: https://phabricator.services.mozilla.com/D229459
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
