Intent to Ship: Feature Policy for Autoplay

[Becca Hughes]

Contact emails

becca...@chromium.org, mlam...@chromium.org, dah...@chromium.org

Explainer

This is a small addition to Feature Policy & HTML and does not need an explainer.

Spec

https://github.com/WICG/feature-policy/blob/gh-pages/features.md

https://github.com/whatwg/html/pull/3253

Summary

Allows developers to selectively enable and disable use of autoplay through the feature policy HTTP header or the <iframe> "allow" attribute.

 

The default value will be “self”. This means that we will allow autoplay on same origin iframes. If developers have cross origin iframes they will be able to enable autoplay on those frames by enabling the "autoplay" feature.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/blink-dev/KTLndMOFLLA/VykZ7bg8BgAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Risks

 

Interoperability and Compatibility

Edge: No signals

Firefox: No signals

Safari: Public support

Web developers: Positive

Ergonomics

This part of Unified Autoplay.

Activation

The feature is backwards compatible so it can be used immediately as-is.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Link to CL.

OWP launch tracking bug

https://crbug.com/788390

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5100524789563392

[Philip Jägenstedt]

It looks like nobody thinks that https://github.com/whatwg/html/pull/3253 is blocked on anything other than doing the final polish, is that right? +Domenic Denicola?

Very exciting to see that testdriver.js is used for the tests here. +Geoffrey Sneddon  +Jonathon Kereliuk FYI.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsEJK9EpP-7Wttq1GXjV1cv4E32UmgEK%3Dgof18eVioh2v6Q%40mail.gmail.com.

[Anne van Kesteren]

On Tue, Dec 12, 2017 at 12:06 PM, 'Philip Jägenstedt' via blink-dev
<blin...@chromium.org> wrote:
> It looks like nobody thinks that https://github.com/whatwg/html/pull/3253 is
> blocked on anything other than doing the final polish, is that right?
> +Domenic Denicola?

Well, it depends on Feature Policy in general becoming an accepted and
integrated part of the platform. I would not quite qualify that as
polish as it still has a couple outstanding issues, including with
respect to HTML integration.


--
https://annevankesteren.nl/

[Mounir Lamouri]

If Feature Policy needs to be merged into HTML in order for this PR to be merged, I do not think it then reasonable to require the PR to land in order for us to ship the change given that Feature Policy has launched in Chrome already and the autoplay keyword was added in the list of Feature Policy features.

-- Mounir

[Philip Jägenstedt]

I agree that integrating FP into HTML ought not block shipping additional bits of FP. It's "accidental" which bits of FP were added first and in later stages, so treating the differently would be odd.

That being said, what is the status of integrating FP into HTML, who's doing the work. Ping +Ian Clelland :)

What is the actual, textual change, that resolving that TODO would amount to? All of the linked terms work, I presume, so will it effectively be editorial?

[Ian Clelland]

On Tue, Dec 12, 2017 at 8:46 AM Philip Jägenstedt <foo...@google.com> wrote:

I agree that integrating FP into HTML ought not block shipping additional bits of FP. It's "accidental" which bits of FP were added first and in later stages, so treating the differently would be odd.

That being said, what is the status of integrating FP into HTML, who's doing the work. Ping +Ian Clelland :)

I'm preparing a PR for HTML that integrates FP more fully, and also updating the "Integrations" section of the FP spec so that the monkey patch is up to date with that PR. Should be out for review this week.

What is the actual, textual change, that resolving that TODO would amount to? All of the linked terms work, I presume, so will it effectively be editorial?

1. Documents need to be defined to have an actual policy object, and there are two places where that needs to be initialized. (Current text incorrectly refers to 'global objects')

2. The document's allow* flags are no longer relevant, and allowfullscreen, allowpaymentrequest and allowusermedia need to reference FP instead. (Allowusermedia needs to be handled as well)

3. The 'allowed to use' algorithm needs to actually take a policy-controlled feature as an argument, and not just "feature indicated by *some attribute*", so that other specs can properly call into it.

4. We should either formalize how FP operates on workers/worklets, or remove that from the spec for now.

There may be more, but discussion should probably be on https://github.com/WICG/feature-policy/issues/95; I'll link the PR to that issue.

[Philip Jägenstedt]

On Tue, Dec 12, 2017 at 4:09 PM Ian Clelland <icle...@chromium.org> wrote:

On Tue, Dec 12, 2017 at 8:46 AM Philip Jägenstedt <foo...@google.com> wrote:

I agree that integrating FP into HTML ought not block shipping additional bits of FP. It's "accidental" which bits of FP were added first and in later stages, so treating the differently would be odd.

That being said, what is the status of integrating FP into HTML, who's doing the work. Ping +Ian Clelland :)

I'm preparing a PR for HTML that integrates FP more fully, and also updating the "Integrations" section of the FP spec so that the monkey patch is up to date with that PR. Should be out for review this week.

What is the actual, textual change, that resolving that TODO would amount to? All of the linked terms work, I presume, so will it effectively be editorial?

1. Documents need to be defined to have an actual policy object, and there are two places where that needs to be initialized. (Current text incorrectly refers to 'global objects')

2. The document's allow* flags are no longer relevant, and allowfullscreen, allowpaymentrequest and allowusermedia need to reference FP instead. (Allowusermedia needs to be handled as well)

3. The 'allowed to use' algorithm needs to actually take a policy-controlled feature as an argument, and not just "feature indicated by *some attribute*", so that other specs can properly call into it.

4. We should either formalize how FP operates on workers/worklets, or remove that from the spec for now.

There may be more, but discussion should probably be on https://github.com/WICG/feature-policy/issues/95; I'll link the PR to that issue.

Great, thanks Ian! I wasn't clear in my question, but I was wondering how this PR would change, textually, i.e. if merging it first would work or not.

But Anne clarified that, the preference is to do the FP<->HTML integration first.

All I think we need here is to keep track of this outstanding work so that it's all done pretty soon, so that others may implement from spec and not open PRs. Becca, can you keep track of that using a method of your choosing?

LGTM1 to ship with that.

[Becca Hughes]

The web-platform-tests have now landed so most of the remaining tasks are on the FP<->HTML integration. I think the GitHub issue is the best place for tracking that and I have updated it with the results of this thread.

Becca

[Ian Clelland]

On Wed, Dec 13, 2017 at 6:30 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Dec 12, 2017 at 4:09 PM Ian Clelland <icle...@chromium.org> wrote:

On Tue, Dec 12, 2017 at 8:46 AM Philip Jägenstedt <foo...@google.com> wrote:

I agree that integrating FP into HTML ought not block shipping additional bits of FP. It's "accidental" which bits of FP were added first and in later stages, so treating the differently would be odd.

That being said, what is the status of integrating FP into HTML, who's doing the work. Ping +Ian Clelland :)

I'm preparing a PR for HTML that integrates FP more fully, and also updating the "Integrations" section of the FP spec so that the monkey patch is up to date with that PR. Should be out for review this week.

What is the actual, textual change, that resolving that TODO would amount to? All of the linked terms work, I presume, so will it effectively be editorial?

1. Documents need to be defined to have an actual policy object, and there are two places where that needs to be initialized. (Current text incorrectly refers to 'global objects')

2. The document's allow* flags are no longer relevant, and allowfullscreen, allowpaymentrequest and allowusermedia need to reference FP instead. (Allowusermedia needs to be handled as well)

3. The 'allowed to use' algorithm needs to actually take a policy-controlled feature as an argument, and not just "feature indicated by *some attribute*", so that other specs can properly call into it.

4. We should either formalize how FP operates on workers/worklets, or remove that from the spec for now.

There may be more, but discussion should probably be on https://github.com/WICG/feature-policy/issues/95; I'll link the PR to that issue.

Great, thanks Ian! I wasn't clear in my question, but I was wondering how this PR would change, textually, i.e. if merging it first would work or not.

I misread, sorry.

With FP integrated into HTML, I think the only change would be that this could call into the "allowed to use" algorithm with something like:

<p>A <span>media element</span> is said to be <dfn>allowed to play</dfn> if:</p>

<ul>

   <li>The <span>media element</span>'s <span>node document</span> is <span>allowed to use</span>

   the <a href="https://wicg.github.io/feature-policy/#policy-controlled-feature">policy-controlled feature</a>

   named <code>autoplay</code>. <ref spec="FEATUREPOLICY"/></li>

   <li>Both the user agent and the system allow media playback in the current context.</li>

</ul>

 

If the 'autoplay' policy-controlled-feature isn't defined anywhere else, it should be formally defined as well (It's in feature policy's non-normative list of "features we know about", but should be in spec text somewhere)

Ian

[Rick Byers]

+1 to foolip's advice

LGTM2

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJgEHvw5qQ9nniesupOJXu-xrCqOrU-CXeQ5nBxwtf3NA%40mail.gmail.com.

[Jochen Eisinger]

lgtm3