When I added ScriptLoader::SetGlobalObject I didn't realise that more than one
document could share the same global object. It turns out that this happens for
these template contents owner documents and this causes the assert that checks
that right module loader is associated with the global to fail because it finds the
other document's module loader.
As far as I can tell we don't need a module load for these documents so we can
skip this call that creates it.
For some reason the test times out on Android and I wasn't able to work out why
so I didn't enable it there.
Differential Revision: https://phabricator.services.mozilla.com/D181267
This changes the spoken on macOS VoiceOVer:
from: "Spanish, collapsed, pop up button"
to: "Spanish, Translate from, collapsed, pop up button"
Differential Revision: https://phabricator.services.mozilla.com/D180969
These were needed due to a bug in the button implementation that has
since been fixed. I don't have the bug number, but I received this
feedback in a review, but the other bug hadn't landed yet.
Depends on D180986
Differential Revision: https://phabricator.services.mozilla.com/D180987
This ensures that the calls to SpecialPowers.spawn are always awaited. It
also changes setupFn to setupAndCompleteFn to clarify that that function
returns a promise, which needs to be setup before the click and awaited
afterwards. It also removes the "async" keyword from functions that return
Promises, but don't await them.
Differential Revision: https://phabricator.services.mozilla.com/D181165
The comment in the test indicates that the intent of the test is to invoke
two calls that should resolve in opposite order (the "race" in the test
title), but that behavior is specific to a synchronous fullscreen
transition. So this patch disables the test for macOS.
Differential Revision: https://phabricator.services.mozilla.com/D181126
This test is checking the state of PiP UI elements in the video window,
and how they change in response to fullscreen. The logic in the test waits
on the fullscreenchange events it receives from the parent process, and
the PiP UI changes depending on the fullscreenchange events it receives
from the content process. The changes in this patch ensure that the PiP UI
elements have time to receive their fullscreenchange events from the
refresh driver. This was already in place for fullscreen exits, presumably
because it was causing problems when transitioning from test-to-test. This
change adds that same pause to fullscreen enters, which gives time for the
UI elements to receive their event and get updated.
Prior to this change, this test was using the pattern of defining async
functions which await other Promises. But the last Promise in the chain
was never awaited. This changes the test to use the pattern of returning
the Promises, which works becauses the calling functions are awaiting
the results of each step in the chain.
It also adds more logging to the test.
Depends on D180884
Differential Revision: https://phabricator.services.mozilla.com/D181123
This adds an additional action that is triggered when the fullscreen
transition event is received. That interim action is used to re-focus the
original tab. Without this change, an asynchronous fullscreen transition
will silently swallow the MozAfterPaint event that is necessary to detect
the end of fullscreen.
Before this change, with asynchronous transitions, here's the flow:
1) The test opens Tab 1 which opens Tab 2.
2) Tab 1 enters fullscreen. This transition takes awhile but signals
success early. This is intentional because we want web content to be able
to be fully layed out when the fullscreen transition is complete.
3) Thinking that it has reached fullscreen, the test focuses Tab 2, which
causes a fullscreen exit transition to be queued up but not yet run.
Then Tab 1 is unfocused and a MozAfterPaint message is sent, but nobody is
listening for it so it has no effect. If the fullscreen transition was
synchronous, the actions of Step 6 (below) would happen before the change
in focus and there would be an event listener ready for the MozAfterPaint
event.
4) The test waits for the DOMFullscreenChild to send the
DOMFullscreen:Painted message, which it will do when it receives a
MozAfterPaint event.
5) Enter fullscreen transition completes, exit fullscreen transition
starts.
6) The MozDOMFullscreen:Exited event is sent to the DOMFullscreenChild,
which starts listening for the MozAfterPaint event. This event has
already been sent.
7) Test times out.
This change adds an additional action to take place between steps 6 and 7.
That additional action refocuses Tab 1. This makes it send another
MozAfterPaint event which the DOMFullscreenChild is ready to receive.
Differential Revision: https://phabricator.services.mozilla.com/D180884
This test is disabled for failures on Android, but the component doesn't run on
Android, so annotate the test skip as such.
Differential Revision: https://phabricator.services.mozilla.com/D179744
Now that we start the ShutdownKill timer only after we actually sent the shutdown message, we want to ensure that a content process that we know will die but did not yet receive the shutdown message will start to idle as early as possible in case the parent process is too busy to send the shutdown message right away.
Differential Revision: https://phabricator.services.mozilla.com/D180960
The parent process might be busy such that the time that passes between NotifyTabDestroying and ShutdownProcess can become significant in terms of activating the ShutdownKill timer too early. In order to avoid this, we will start the timer only after we actually sent the shutdown message.
To cover the time that passes between NotifyTabDestroying (right after sending a delete to the Browser actor) and the effective NotifyTabDestroyed (in response to the Browser actor destroy roundtrip through the content process), we add a second timer that triggers the sending of the shutdown message.
Differential Revision: https://phabricator.services.mozilla.com/D180959
We won't add the default fingerprinting protection targets if the
override pref is empty. This is undesirable, we should still add the
default RFPTargets in this case.
Differential Revision: https://phabricator.services.mozilla.com/D180869
This adds two new mach commands:
`mach wpt-fetch-logs` which can download log files from mozilla CI or
taskcluster runs on GitHub.
`mach wpt-interop-score` which can download runs and compute the
interop score. By default this filters tasks to those most like
upstream CI i.e. linux64 opt builds.
The actual implementation is mostly in external packages; the mach
commands are mostly frontends to these.
Differential Revision: https://phabricator.services.mozilla.com/D180731
