Add "not-allowed" error code to SpeechSynthesis

[csharrison]

This error is designed to be analogous to

1. https://webaudio.github.io/web-audio-api/#allowed-to-start
2. https://html.spec.whatwg.org/multipage/media.html#allowed-to-play

This leaves it up to the user agent if speaking should be allowed or not.

---

Preview | Diff

[csharrison]

@minorninth @mounirlamouri @foolip FYI

The existing text to this spec do not really formalize when these errors will be fired. I could add a section to the "speak" section if it adds clarity.

Dominic also suggested offline to spell this like "needs-user-interaction" but I preferred to keep this in line with WebAudio / Media and leave it open to the UA to decide when speech is allowed.

[foolip]

@csharrison these changes LGTM. I'd like to see this tested in web-platform-tests as well. Web Audio and HTML don't say anything normative about when playback should be refused, but I'd be happy to see it spelled out normatively in https://w3c.github.io/speech-api/#dom-speechsynthesis-speak. As you can see the prose in this spec isn't algorithmic or too precise, but if you can reference https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation and "not-allowed" in the same sentence, that'd be enough to write a test for it. Would you mind doing that? Thanks!

[csharrison]

@mounirlamouri Can you give any more historical context for why neither WebAudio / HTML specs spell out when playback should be refused? My fear is that this was chosen for a good reason, and that we should be cautious when diverging from the status quo.

[csharrison]

I've written some WPT that exercise this error path in web-platform-tests/wpt#12327

[mounirlamouri]

The rules for autoplay vary between browsers and as of today, I do not think any two browser follow the same set of rules. Because the rules to set autoplay are deeply related to the expected user experience, we have left them as "user agent details" for now. The hope is that we will converge to a set of rule we all agree on.

[csharrison]

Thanks! @foolip, let me know if you still want the normative changes applied here given the context in #28 (comment).

[foolip]

@mounirlamouri are there tracking issues for converging on the conditions for when autoplay shouldn't work, i.e. the bits that would be required to be able to have a test that asserts that playback fails video.play() (or equivalent) is simply called from script?

@csharrison, how about filing an issue in this repo to define the precise condition, link that to any other similar issues in HTML / Web Audio, and then making the failure test in web-platform-tests/wpt#12327 tentative?

[foolip]

Spec and test changes merged, thanks @csharrison!

[mounirlamouri]

@foolip my plan was to discuss this with other browsers are TPAC and whether we could start an "autoplay" spec that could try to put into spec word some of the logic. Nothing more than this idea exist at the moment :)