On 8/1/18 3:36 AM, Chris Pearce wrote:
On Tuesday, July 31, 2018 at 9:05:03 AM UTC+12, Jan-Ivar Bruaroey wrote:
On 7/29/18 10:39 PM, Chris Pearce wrote:
Summary: HTMLMediaElement.allowedToPlay allows web authors to determine in
advance of calling HTMLMediaElement.play() whether the HTMLMediaElement in its
current state would be allowed to play, or would be blocked by the browser's
autoplay blocking policies.
This is useful to web authors as if they can't autoplay they may prefer to
download a poster image instead of paying the price of downloading media data.
This feature is particularly useful for Firefox, as web authors can poll
HTMLMediaElement.allowedToPlay to determine whether a permission prompt would
show if they were to call play().
Doesn't this amputate the user flow we just implemented?
Without this attribute, Netflix queues up rich media, Firefox asks the
user if they want autoplay, who answers "Duh, it's Netflix", and levels
up to auto-playing Netflix forever.
With this attribute, Netflix sees HTMLMediaElement.allowedToPlay ==
false, and downloads a poster image instead. User must click to get
engaging media, which now takes longer to load, and they never level up
to auto-playing Netflix?
Doesn't seem like an improvement. Am I missing something?
Without this attribute, sites that are determined to avoid showing the doorhanger have no
option other than to never autoplay ever in Firefox. With this attribute, they can detect
when they can "safely" start to autoplay video if the user otherwise unblocks
autoplay.
My first reaction to this was:
How can the user unblock autoplay on sites determined to never show the
doorhanger?
But then I realized we're mixing terms.
With "user otherwise unblocks autoplay" you mean "user gesture".
What I call "unblocking autoplay" you call "whitelisting".
It sounds like allowedToPlay would be used to entirely sidestep the
autoplay permission model we just implemented, rendering Firefox
identical to Chrome in behavior.
Except not identical, but much poorer, since Chrome would whitelist
Netflix, whereas our plan for that was to ask users once, with a
"remember=yes" prompt. If sites sidestep this prompt, then what's our
whitelist story?
Don't we need a functional plan to let users whitelist Netflix? Doesn't
this attribute work against that?
To continue your example of Netflix, if the user clicked somewhere, say to
select their Netflix profile, or click to login or a browse a category or
side-scroll their catalog, then they'd gesture activate the document and the
site would be able to autoplay, without a doorhanger.
I think you're basically correct that sites that actively use allowedToPlay to
avoid the doorhanger would also avoid being whitelisted.
Netflix doesn't need a new API to circumvent our doorhanger and blast
audio on the first user gesture. That seems easily shimmable:
1. Test Firefox version
2. If new, avoid autoplay on pageload
2. various.forEach((t, n) => t.addEventListener(n, () => audio.play());
What's the benefit to users from standardizing an API to circumvent our UX?
I think the only thing that you're missing is how vehemently some sites are in
their desire to avoid the doorhanger prompt.
No, I'm also missing why we should listen to them.
If Netflix fights our doorhanger, then they're fighting our best attempt
to whitelist them.
Regardless, something being contentious is usually a bad sign for
standardization.
cpearce.
.: Jan-Ivar :.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
