Automatic update from web-platform-tests
Mark media-source/idlharness test as slow
The test often times out on the waterfall.
Tbr: chcunningham@chromium.org
Change-Id: I47cc2c795f0ff4163e952d1cce971388b7a67760
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1773524
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#690852}
--
wpt-commits: 9e76bf3a36549abc01a511a309b8aeec0975fe6d
wpt-pr: 18707
Automatic update from web-platform-tests
Explain the split between the two idlharness tests in dom/ (#18708)
--
wpt-commits: 9ae3cc7e3f5420538b709a91149f4f811bc4bb42
wpt-pr: 18708
Automatic update from web-platform-tests
Replace setTimeout with step_timeout in inert/ tests (#18541)
This avoids the need to silence the lint.
--
wpt-commits: baa77c77ae1328ce146dcb699588141e2ed6bf80
wpt-pr: 18541
And this fixes the caller which has not guaranteed the lifetime of the
start container.
Differential Revision: https://phabricator.services.mozilla.com/D44175
--HG--
extra : moz-landing-system : lando
The mach driver will now run all misspelled commands with Python 3. That means
we can't automatically execute the suggested command anymore, as it may need to
run against Python 2.
Ideally we could figure out a way to check the command against the 'mach'
whitelist, but until then, let's just disable automatic execution. Worst case
scenario we can turn it back on after the migration has finished.
Differential Revision: https://phabricator.services.mozilla.com/D44282
--HG--
extra : moz-landing-system : lando
So that we can restrict QI(nsIIdentChannel) to nsIHttpChannel and DocumentChannelChild objects only.
Differential Revision: https://phabricator.services.mozilla.com/D44111
MANUAL PUSH: multiple authors stack
DocumentChannel acts as a replacement for HttpChannel where redirects are now entirely handled in the DocumentChannelParent. The ContentChild will receive the final nsIChannel once all redirects have been handled.
Differential Revision: https://phabricator.services.mozilla.com/D37490
We can deduct it from the nsIChannel argument already. In the future, the httpParent may be either HttpChannelParent or DocumentChannelParent.
Differential Revision: https://phabricator.services.mozilla.com/D40971
The devtools listens to http-on-opening-request event which is expected to receive a nsIHttpChannel. However future changes will make it that it's not always a nsIHttpChannel that can fire such event.
As such we create an intermediary interface nsIIdentChannel and move the subset generating such event in nsIHttpChannel there.
Differential Revision: https://phabricator.services.mozilla.com/D40968
This more closely follow the code as earlier documented. To remove all ambiguities, the idl documentation was amended.
Differential Revision: https://phabricator.services.mozilla.com/D40961
This class allows to encapsulate all the information required in order to create a new HttpChannel object following a redirect.
Differential Revision: https://phabricator.services.mozilla.com/D40959
This method & the chunkCountLimit_ variable are unnecessary. The maximum
permitted nursery size is tracked in the GCSchedulingTunables class.
Differential Revision: https://phabricator.services.mozilla.com/D39285
--HG--
extra : moz-landing-system : lando
The new variable, 'newMinNurseryBytes' is more in-line with the other
'newMaxNurseryBytes'.
Differential Revision: https://phabricator.services.mozilla.com/D39284
--HG--
extra : moz-landing-system : lando
We used to calculate the nursery's maximum size in chunks, and track the
maximum number of chunks permitted. This could lead to some unexpected
behaviour with a larger nursery than requested. Calculating it in bytes is
simpler, avoids this problem, and is more in-line with other calculations.
Differential Revision: https://phabricator.services.mozilla.com/D39281
--HG--
extra : moz-landing-system : lando
