Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
I don't think we should allow media without audio tracks to autoplay because:
* It means play() before loaded metadata behaves differently than play()
called after loaded metadata.
* With the current impl we dispatch the "play" event and then the "pause"
event when we decide we should block, which may confuse some sites' controls.
* Delaying running the play() algorithm until we've loaded metadata would add
significant complexity, and may break sites.
* Chrome doesn't have this provision, meaning the complexity required to
support it will not result in much benefit to us.
MozReview-Commit-ID: FSVlDJAOisw
--HG--
extra : rebase_source : 93b1bcf8d8edbd6ca10ad918b40a87cd3cfbbf0b
We only should do the camera/mic permission or active capture test in
the case where document gesture activation is enabled.
MozReview-Commit-ID: 9xSe8FDn5tu
--HG--
extra : rebase_source : fb19fdcc7003d7ba04f5f1ab3a7d51ce63abc3db
extra : intermediate-source : 7de5bdbef79bacbee3284d49b77de36aceb0270e
extra : source : e72b9f4dcf418d4fcd2a0698f601d42eb9b0ecc0
Audio context would be allowed to start if
(1) its document has been activated by user gesture
(2) it's a offline audio context, because it won't directly output sound to audio
devices
In addition, all resume promises would be pending until audio context has been
allowed and user calls resume() again.
MozReview-Commit-ID: G6RV8dDM6vQ
--HG--
extra : rebase_source : bc1d2ad0594ad1f54c05ade06495918aaee14911
extra : source : 5031770d70fd643230cb4caf6a5106616adaf0fd
Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4a974aba0533bfbd5e9bb4c4c11d77d17a81db6d
Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4d9afdec0caa4a82b53bedfd645f259a5c760e4d
It seems reasonable to assume that when a page has been granted permission
to capture camera/microphone, the user intends it to play audible media.
MozReview-Commit-ID: 1RdsPK1vRPt
--HG--
extra : rebase_source : 688b68c29d73f117a2cc376233d664bc9cdb5d52
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : 83e53a0035d72984494948f131a5d6e516baa577
If the media has started playing before, bless it and it would always be allowed
to autoplay.
MozReview-Commit-ID: 4GqMARLXULU
--HG--
extra : rebase_source : 2fdb3937156147755f8e387b1d84311ae1d37ce4
If the media has started playing before, bless it and it would always be allowed
to autoplay.
MozReview-Commit-ID: 28X4TmG25aJ
--HG--
extra : rebase_source : 3fd7cb16da9e7f925ad7020fb74c48537e08a996
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : 97315d90fa46a16289135ac7490bd0dab651d682
This patch is mainly reverting the changing of bug1382574 part3, but not all the same.
Since youtube would call load() when user clicks to play, and then call play()
later. For the old pref (checking user-input-play), we should still allow the
following play() even it's not triggered via user input. It's also same for
seeking, Youtube would call play() after seeking completed.
In this patch, we would allow the script-calling once play() if user has called load()
or seek() before that.
MozReview-Commit-ID: 1UcxRCVfhnR
--HG--
extra : rebase_source : c72212ebf29ea624128a8190dab67e1197f1f198
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : fa8d1bfd2fb667e974dbe499d7f8215273d4fa10
AutoplayPolicy is used to manage autoplay logic for all kinds of media,
including MediaElement, Web Audio and Web Speech.
MozReview-Commit-ID: R1TxMkarIw
--HG--
extra : rebase_source : 8c608a1d12c8e205391a91f22e1532bc4f2c8f16
