This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
I changed this test earlier in this set of commits to use
midflight-redirect.sjs so that we get more reliable and predictable cross
origin redirects during the download. Unfortunately this test now times out on
Windows.
This test times out on Windows because midflight-redirect.sjs redirects at 1/4
through the resource, whereas this test expects to be able to play through to
1/5 through the resource, and on Windows that seems to be not reached during
playback. This is likely due to decode latency being higher on Windows.
On top of that, the test's first case can sometimes call MediaRecorder.start()
before the redirect has happened, and before the principal has changed, and so
start() doesn't throw a SecurityError as expected, and the test intermittently
fails.
Additionally, the test's code could be clearer if we used async/await.
So rewrite the test to use async/await, and take advantage of
midflight-redirect.sjs's redirect being more predictable than the old
dynamic_redirect.sjs. Basically, we can be careful to wait for either
"loadedmetadata" or "error" on the media element in order to be more confident
the redirect has or hasn't happened yet.
We still can't be 100% sure that the redirect won't have already happened by
the time our "loadedmetadata" handlers run. It's quite possible that the
download has reached 1/4 through the resource by the time the loadedmetadata
handler has run, so we need to handle the "error" and "loadedmetadata" events
racing.
MozReview-Commit-ID: 8plMjkXgjYt
--HG--
extra : rebase_source : 7305598f40c09219494f3e7150799d8875b7c30e
We have two SJS files; midflight-redirect.sjs and dynamic_redirect.sjs,
which are very similar, but dynamic_redirect.sjs is buggy, so we should
just use midflight-redirect.sjs.
dynamic_redirect.sjs is buggy because it relies on the client doing multiple
HTTP requests to it in order to redirect, but we can't actually guarantee
this. Previously users of it would try things like setting a small MediaCache
size, or only using Ogg for which we expect a seek to the end to calculate
the duration, but I have observed the entire resource being downloaded in
one hit before the media element has finished loading metadata, meaning the
seek (in the Ogg case) can happen without another HTTP request. This is even
with a small MediaCache.
midfligh-redirect.sjs solves this problem by explicitly only returning a
partial response, so the client is forced to make another HTTP request,
which we will serve a redirect to.
MozReview-Commit-ID: 39imyayhnBG
--HG--
extra : rebase_source : 603532e4af0bf304c34739de5b0b243174e3831d
dynamic_redirect.sjs and midflight-redirect.sjs are serving files
with "Content-Type: video/ogg", which is incorrect and could lead
to problems given that we're not always asking it to serve Ogg
files. So include the type be to served as a query parameter.
MozReview-Commit-ID: 5f0PXy8lL3G
--HG--
extra : rebase_source : 757395a21317655422767efe3f7c1923a19c0114
Change where load calls are used in media recorder principals test to more
reliably force cross origin requests.
MozReview-Commit-ID: 7La6ZIRmsTQ
--HG--
extra : rebase_source : 58b8049de46ad5800300033dd4ee101e68171c70
Update the MediaRecorder principal test to behave more like
test_mixed_principals.html. This involves preloading metadata and using a
longer video to test with. This particular combination currently results in
multiple requests being made for the resource, however this is not a robust
solution in that the behaviour of the MediaCache and associated objects may
change and break this. This fixes the issue for now as best I can tell, but
a follow up gtest or may be a more sensible long term solution.
MozReview-Commit-ID: F9gnnzGt3Cu
--HG--
extra : rebase_source : 8444f135033fbed350266ebfe5faafc245ff5596
MediaRecorderErrorEvent is now fired in response to async errors in the
MediaRecorder. This event wraps a DOMException and tests need to be updated to
reflect this new behaviour.
MozReview-Commit-ID: JIjIZlJJ8PE
--HG--
extra : rebase_source : b8adde26f5321b5b8a3c8e193c5744d6f3403cf5
MediaRecorderErrorEvent is now fired in response to async errors in the
MediaRecorder. This event wraps a DOMException and tests need to be updated to
reflect this new behaviour.
MozReview-Commit-ID: JIjIZlJJ8PE
--HG--
extra : rebase_source : f9667b8a1b2a82959624831f3ef5109c19fccbd6
Update the MediaRecorder principal test to behave more like
test_mixed_principals.html. This involves preloading metadata and using a
longer video to test with. This particular combination currently results in
multiple requests being made for the resource, however this is not a robust
solution in that the behaviour of the MediaCache and associated objects may
change and break this. This fixes the issue for now as best I can tell, but
a follow up gtest or may be a more sensible long term solution.
MozReview-Commit-ID: F9gnnzGt3Cu
--HG--
extra : rebase_source : 73f56e256c21f5a775e0fa2a32606d7f7553bd4e
Brian Grinstead
Chris Pearce
Bryce Van Dyk
Wes Kocher
Andrea Marchesini
Sebastian Hengst
Jan-Ivar Bruaroey