Intent to Remove: Prefixed WebAudio AudioContext and OfflineAudioContext

116 views
Skip to first unread message

Raymond Toy

unread,
Dec 1, 2016, 6:20:55 PM12/1/16
to blink-dev, Philip Jägenstedt

Primary eng (and PM) emails

rt...@chromium.org, hong...@chromium.org


Link to “Intent to Deprecate” thread

No deprecate thread; a deprecation message was added in https://crbug.com/405346


Summary

Remove webkitAudioContext and webkitOfflineAudioContext in favor of AudioContext and OfflineAudioContext.  We plan on removing the prefix in M58, but also updating the current deprecation message to mention explicitly this milestone for removal.


Motivation

This aligns WebAudio with the specification and Chrome’s general desire of not using prefixed features anymore.


Compatibility Risk

There is some small risk of breaking existing applications.  Chrome has supported WebAudio since mid-2011 or so and, of course, so did Safari.  Firefox introduced WebAudio in 2013.  Edge supports WebAudio, but Internet Explorer has not and will not.  Chrome has supported both the prefixed and unprefixed version but Firefox and Edge have never supported a prefix version.  Safari, however, still only supports the prefixed version.


Usage information from UseCounter

https://crbug.com/665887 has an analysis of the usage and what would break. (Thanks to foo...@chromium.org for doing the analysis.)  Only 17 were judged to be problematic and of those, only one would seem to be broken by this change, except it was already broken because it uses createGainNode which was renamed to createGain many years ago.


OWP launch tracking bug

https://crbug.com/665887


Entry on the feature dashboard

https://www.chromestatus.com/feature/4571020824412160


Philip Jägenstedt

unread,
Dec 1, 2016, 6:26:11 PM12/1/16
to Raymond Toy, blink-dev
I will recuse myself since I filed the bug and did the httparchive research. I definitely think we should do this. Given that the usage in the wild so overwhelmingly uses fallbacks, I don't think that adding a date to the deprecation message for a cycle would be of much value. It's been deprecated for so long that most people motivated to investigate have already done so.

Raymond Toy

unread,
Dec 1, 2016, 6:30:13 PM12/1/16
to Philip Jägenstedt, blink-dev
Are you suggesting not to update the deprecation message and just suddenly remove it in M58?

Philip Jägenstedt

unread,
Dec 2, 2016, 6:04:14 AM12/2/16
to Raymond Toy, blink-dev
I would find that acceptable given how rarely the message will be indicative of a real problem, but if anyone wants to err on the side of updating it, I certainly won't mind.

Rick Byers

unread,
Dec 2, 2016, 11:47:01 PM12/2/16
to Philip Jägenstedt, blink-dev, Raymond Toy
IMHO no reason Philip's vote shouldn't count, so I'm going to go straight to LGTM2  😀.

I agree the warning looks like much more noise than benefit, let's just remove outright.

Really great analysis on this one guys, thanks!

Chris Harrelson

unread,
Dec 3, 2016, 1:40:14 PM12/3/16
to Rick Byers, Philip Jägenstedt, blink-dev, Raymond Toy
LGTM3

--
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+unsubscribe@chromium.org.

Joe Medley

unread,
Jan 26, 2017, 3:25:34 PM1/26/17
to blink-dev, foo...@chromium.org, rt...@chromium.org
FYI, the removal is in M57, not M58 as suggested below.
Reply all
Reply to author
Forward
0 new messages