There are several functions related with an element's visibie state, which are confusing. So this patch is going to make them clearer and remove unnecessary function.
- `IsVisible()` : add description to mention that the visibility state is only for layout level, which doesn't represent the actual visible state.
- rename `IsHidden()` to `IsActualInvisible()` : make it represent the actual visible state of an element.
- remove `IsActive()` : current two callers of `IsActive()` only care about if the page is inactive or not, it doesn't care about if page hidden or not. So we can call the owner doc's method directly.
Differential Revision: https://phabricator.services.mozilla.com/D101107
Append a video element to document with loading the test video triggered 'mozentervideosuspend' event. It caused the test failure.
Differential Revision: https://phabricator.services.mozilla.com/D21499
--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
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
alwu
Mark Banner
Narcis Beleuzu
sotaro
Chris Pearce
Dan Glastonbury
Kaku Kuo
Iris Hsiao
JW Wang
Dan Glastonbury