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
These two tests had intermittent orange failures. The logging shows
that the suspend happens but the `ended` event is never received.
Test re-written on the presumption that `ended` event is fired and
lost between checking `video.ended` and registering `ended` event in
`waitUnitEnded()`
MozReview-Commit-ID: GnAFADFOJje
--HG--
extra : rebase_source : 2e9d79e328bbc007ea4f9a7a9dce070619d9e32f
Test:
- That video decode suspends when enabled and delay is reached.
- That video decode doesn't suspend when disabled.
- That video decode doesn't suspend when video finishes before suspend delay.
These tests need to run from content process to observe the suspend
notifications via nsIObserverService, but access to gBrowser is in
chrome process in e10s. Thus, the reason for loading
background_video_chrome.js into chrome process and invoking functions
via async messages.
MozReview-Commit-ID: 2eE97FEUMPu
--HG--
extra : rebase_source : e48cc4dab54648bf0830f59f346a09ab3fb73f6e
