Intent to Ship: AudioContext.onerror

[Ajay Rahatekar]

Contact emails

hong...@chromium.org, mjwi...@chromium.org

Explainer

None; the specification (W3C Proposed Recommendation) is already published.

Specification

https://webaudio.github.io/web-audio-api/#dom-audiocontext-onerror

Summary

Introduces an event listener on AudioContext to notify developers of audio device or rendering system failures.

Blink component

Blink>WebAudio

Motivation

Currently, developers lack visibility into the success or failure of their AudioContext, whether during its creation or while actively rendering audio. In the event of failure, web applications misleadingly continue to function as if audio playback is proceeding normally. The AudioContext.onerror event listener allows web applications to proactively respond to and manage device or rendering failures.

Initial public proposal

https://github.com/WebAudio/web-audio-api/issues/2567

TAG review

http://github.com/w3ctag/design-reviews/issues/950 

TAG review status

Resolved

Risks

Interoperability and Compatibility

Gecko: Positive  (http://github.com/mozilla/standards-positions/issues/1016)

WebKit: Defer to Audio WG (https://github.com/WebKit/standards-positions/issues/340)

Web developers: Positive (2020 Developer Survey)

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

No, AudioContext failure scenarios cannot be tested in WPTs. Chromium-internal tests will fully exercise this scenario.

Flag name on chrome://flags

None

Finch feature name

AudioContextOnError

Non-finch justification

N/A

Requires code in //chrome?

False

Tracking bug

https://crbug.com/41495720

Launch bug

https://launch.corp.google.com/launch/4317143

Estimated milestones

M128

Note

The team has requested Privacy and Security approval on the chromestatus entry. The same gates have already been approved on the internal launch bug.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5113439453446144

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

I've filed a spec issue that I believe should be addressed before shipping (with appropriate test updates, etc.) https://github.com/WebAudio/web-audio-api/issues/2590

[Hongchan Choi]

Hi Domenic,

Thanks for your input! I've addressed the issue you opened with 2 PRs:

- https://github.com/WebAudio/web-audio-api/pull/2593

- https://github.com/WebAudio/web-audio-api/pull/2592

Regarding the test updates, what would you like to see other than basic IDL tests? This event can be dispatched only with device failure, which is impossible to emulate on WPT.

Or do we want a more involved "device mocking" for testing?

Best,

Hongchan

[Domenic Denicola]

LGTM1, thanks for the prompt action!

On Mon, Jul 15, 2024 at 11:22 PM Hongchan Choi <hong...@chromium.org> wrote:

Hi Domenic,

Thanks for your input! I've addressed the issue you opened with 2 PRs:

- https://github.com/WebAudio/web-audio-api/pull/2593

- https://github.com/WebAudio/web-audio-api/pull/2592

Regarding the test updates, what would you like to see other than basic IDL tests? This event can be dispatched only with device failure, which is impossible to emulate on WPT.

You're right. I forgot that aspect of the problem, and agree that makes the event type not realistically testable.

 

Or do we want a more involved "device mocking" for testing?

It would be ideal to have such device mocking, with WebDriver or similar technologies. However, it's not a blocker for shipping. And realistically, of all the currently-untestable things that it would be nice to add WebDriver support for, this particular error case doesn't seem too high on the list to me. 

(Although maybe it is, e.g. if you're working with a partner who would really appreciate being able to write automated tests for their website's behavior in such error cases?)

So, my recommendation would be to file a bug on web-platform-tests/wpt with "type:untestable" documenting this gap. But unless you hear great demand from web developers for writing such automated tests, that bug will probably just stay open with low priority. And again, none of this blocks shipping.

[Mike Taylor]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-dUajtpv%2B%2BA8gQSzrSwTapD%2B6s7mXe1%2BHgP6LAaKYKYg%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f215df3a-1265-455e-85d7-2ddb950f280c%40chromium.org.