Re: Sites using webkitAudioContext only

This is already a real problem; there are shipped games out there based on
my compiler/libraries that break under modern Aurora/Nightly builds of
Firefox due to Web Audio. Any authors who don't know to pull down the
latest versions of my libraries will get broken games in FF, and will
probably break if Chrome's implementation ever changes. To the average
player or developer, it looks like an inexplicable regression - add to this
the inevitable actual bugs in implementations/apps... I can only imagine
how bad things could get if, some time down the road, the Web Audio API
gets revved again to make necessary changes, or another browser vendor like
Microsoft decides to integrate it and now webapp/game devs have more
compatibility targets to deal with.

Are there other ways we could identify uses of the old API names in the
wild? Like, is it possible to hook into search crawlers like GoogleBot or
Bing's spider, and have them flag any .js files containing 'AudioContext'
or 'webkitAudioContext'?

Is the compatibility picture just too difficult here? As a crazy strawman,
could it just be decided that as convention we want end users to load a
shim library off JS CDNs like the ones they grab jQuery from, instead of
rehosting, so that implementations can be updated as the spec evolves? I
don't even know if that would actually solve the problem, just trying to
think of some possible way we can address these issues. I want to see the
Web Audio API improved, but somehow the relatively minor tweaks we've had
so far are already causing issues, and that's unfortunate.

-kg

On Fri, Jun 14, 2013 at 4:17 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sat, Jun 15, 2013 at 9:45 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> We are open to removing the old names from Blink; however, I expect we
>> will begin by offering a clean unprefixed version, and work hard at
>> evangelizing to move developers over to that standards implementation; we
>> can then remove the prefixed version at some point in the future (after
>> doing console warnings, etc., to deprecate its usage).
>>
>
> The problem is that this all needs to be done very soon.
>
> Mozilla needs to ship something soon; we're hoping to ship in a release in
> about 14 weeks. If we ship only the new names then a lot of existing
> content won't work, even content that authors expect should work since they
> used AudioContext || webkitAudioContext, or similar. People will complain
> that our implementation is broken and get the impression Web Audio doesn't
> work properly in Firefox. That is very damaging and takes a long time to
> recover from.
>
> So, I'm adamant that whatever we ship needs to be compatible with where
> Chrome is going to be in 3 months, at least for authors who've done
> AudioContext || webkItAudioContext. So if Google can't commit to removing
> the old names from AudioContext in a Chrome release by then, I think we
> need to keep them. (Retaining them in webkitAudioContext may be OK.)
>
> Rob
> --
> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
> qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
> qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq
> qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq
> qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q
> qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
>