Returning a span ensures that consumers don't try to use this without a length,
but does hide the fact that our string is always null-terminated, at least for
the moment...
Differential Revision: https://phabricator.services.mozilla.com/D49531
--HG--
extra : moz-landing-system : lando
Calling browserLoaded without a |wantLoad| after a call to both addTab and
loadURI may resolve with either of the two loaded urls (usually the first). This
patch updates some callsites to remove any possible non-determinism.
Differential Revision: https://phabricator.services.mozilla.com/D49004
--HG--
extra : moz-landing-system : lando
Since BrowserTestUtils.firstBrowserLoaded now resolves slightly later than it
did before, the STATE_STOP notification is dispatched before we get a chance
to add the progress listener in BrowserTestUtils.browserStopped. We should
create both Promises before waiting for the initial load to finish.
Differential Revision: https://phabricator.services.mozilla.com/D50018
--HG--
extra : moz-landing-system : lando
Adds BrowserTestUtilsChild.jsm to the whitelist, and removes content-utils.js.
The BrowserTestUtils actor now listens for "load" and "DOMContentLoaded" events,
so it gets instantiated earlier than before.
Differential Revision: https://phabricator.services.mozilla.com/D49003
--HG--
extra : moz-landing-system : lando
This also updates the two functions (BrowserTestUtils.firstBrowserLoaded,
browser_broadcastchannel.js#browserFrameLoaded) that rely on the previous
event to use the new one.
Differential Revision: https://phabricator.services.mozilla.com/D49002
--HG--
extra : moz-landing-system : lando
Previously there was a somewhat strange setup where we had both TestResolver
and TestMetadata classes. Both had 'resolve_tests' function and the separation
of concerns between the two were not clear.
With this change, all of the logic that is related to manipulating and
resolving the loaded tests has been moved to the TestResolver class. Also, the
TestMetadata class has been renamed to TestLoader, and it is solely responsible
for loading the metadata (from the build backend).
Future commits will add other types of TestLoaders.
Differential Revision: https://phabricator.services.mozilla.com/D49768
--HG--
extra : moz-landing-system : lando
A minor cleanup. Re-write paths will now automatically be joined to
self.topobjdir.
Depends on D49766
Differential Revision: https://phabricator.services.mozilla.com/D49767
--HG--
extra : moz-landing-system : lando
Similar to the vcs change, the MozbuildObject already has a reader attribute
available. So we can re-use that instead of creating our own.
Depends on D49765
Differential Revision: https://phabricator.services.mozilla.com/D49766
--HG--
extra : moz-landing-system : lando
Encapsulates all the logic around generating and loading the build backend
metadata on the TestMetadata class. Previously the TestResolver would trigger
the generation if necessary, and TestMetadata would load it. Now both
generation and loading happens in TestMetadata.load_tests.
This change also adds some convenience properties to make it easier to query
the loaded data.
Differential Revision: https://phabricator.services.mozilla.com/D49765
--HG--
extra : moz-landing-system : lando
This prevents us from adding the puppeteer tests over and over again. It
follows the wpt example.
Differential Revision: https://phabricator.services.mozilla.com/D49790
--HG--
extra : moz-landing-system : lando
Since TestResolver is a subclass of MozbuildObject, there's no need to create
separate repository object. It already has one.
Depends on D49761
Differential Revision: https://phabricator.services.mozilla.com/D49764
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
This completes my review of skipped Android tests.
Differential Revision: https://phabricator.services.mozilla.com/D49954
--HG--
extra : moz-landing-system : lando
Depends on D49870
We fail coop-sandbox.https.html without this, since the changes in bug 1566868 don't apply to DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D49871
--HG--
extra : moz-landing-system : lando
We fail navigation-redirect.https.html?client without this (with the subtest to redirects to a cross-origin page and then redirects back again to a same-origin page). In this case the ClientChannelHelper running in the child only sees a same-origin redirect (the first URL to the final one), but we've still allocated a new ClientInfo in the parent and we want to create the corresponding ClientSource.
Differential Revision: https://phabricator.services.mozilla.com/D49870
--HG--
extra : moz-landing-system : lando
We want this to run in both processes so that we set the cspToInherit on the LoadInfo within the child as well as the parent.
Differential Revision: https://phabricator.services.mozilla.com/D47355
--HG--
extra : moz-landing-system : lando
Pick commits:
92e2e11 - minor style fix
5163960 - Update authors
fdb0b1d - Make utf8_from_cfstringref work with empty CFStringRef (#20)
a39bf5f - Remove a fixed issue
Differential Revision: https://phabricator.services.mozilla.com/D50002
--HG--
extra : moz-landing-system : lando
This issue happens when VR/GPU haven't connected with the parent process via IPC protocol, and we are trying to access its IPC Child when it is still null. It is possible to be happened when GPU/VR process is killed/shutdown, and we are trying to launch a new VR process. We need to check these status before completing our VR process's launch.
Differential Revision: https://phabricator.services.mozilla.com/D46540
--HG--
extra : moz-landing-system : lando