Closed Bug 985805 Opened 6 years ago Closed 6 years ago

Remove the legacy Web Audio APIs

Categories

(Core :: Web Audio, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla32

People

(Reporter: ehsan, Assigned: ehsan)

References

Details

Attachments

(3 files)

Are we ready to do this?  Does it make sense to keep these methods around any longer?

If you guys give me the green light, I'd be happy to write the patches.
Flags: needinfo?(roc)
Flags: needinfo?(paul)
Flags: needinfo?(karlt)
I don't know.
Flags: needinfo?(roc)
So, since we shipped Web Audio, I never used the pref to test something.

Blink has an unprefixed implementation in Chrome Canary, but some old names are still there: creatJavaScriptNode, createGainNode, for example (even when you create the context using the AudioContext name). However, they told us they needed a transition period, and they'll remove the old names when they feel they can.

Safari does not have an unprefixed AudioContext, and won't remove old names anyways, so it should not slow us down.

In light of this, I think we can remove the old names support and the associated pref. We could also remove the old synchronous createBuffer that works on compressed data, I'm sure cpearce would be happy.

Jordan Santell (CC-ed) is working on a Web Audio editor/debugger for the devtools. I'm sure it would not be too hard to add an option to use the old names in his tool (that works by intercepting calls to Web Audio API functions, by monkey patching), if we find later that we need to check something.
Flags: needinfo?(paul)
I have used the prefs to test some pages, though not very often.
The need is reducing due to having enough other content for testing.
Having an easy way to monkey patch a document would certainly make the prefs unnecessary.
I don't know that we'd need to offer that to developers though.
Perhaps a bookmarklet would be sufficient.
Flags: needinfo?(karlt)
I can see that some of these are baggage we don't need, such as SyncDecodeMedia, so please feel free to remove at least these.  I don't mind if you want to remove them all even.  I can find an old browser if I need to test something.
Depends on: 999908
Assignee: nobody → ehsan
Comment on attachment 8417145 [details] [diff] [review]
Part 1: Remove support for the legacy BiquadFilterNode extensions; r=padenot,smaug

r?smaug for WebIDL changes.

r?padenot for general correctness/comprehensiveness.
Attachment #8417145 - Flags: review?(paul)
Attachment #8417145 - Flags: review?(bugs)
Attachment #8417146 - Flags: review?(paul)
Attachment #8417146 - Flags: review?(bugs)
Attachment #8417147 - Flags: review?(paul)
Attachment #8417147 - Flags: review?(bugs)
Attachment #8417145 - Flags: review?(paul) → review+
Attachment #8417146 - Flags: review?(paul) → review+
Attachment #8417147 - Flags: review?(paul) → review+
Attachment #8417145 - Flags: review?(bugs) → review+
Attachment #8417146 - Flags: review?(bugs) → review+
Attachment #8417147 - Flags: review?(bugs) → review+
OS: Mac OS X → All
Hardware: x86 → All
These were hidden flags used by Gecko hackers.  No need to document our internal changes and no site-compat issue either, since these APIs were never exposed to the Web.
Okay, thanks!
Looks like those APIs were exposed before (Bug 886165) and hiding them behind the prefs actually broke Google Play Music (Bug 911837). So I'll document this anyway for reference.
(In reply to Kohei Yoshino [:kohei] from comment #13)
> Looks like those APIs were exposed before (Bug 886165) and hiding them
> behind the prefs actually broke Google Play Music (Bug 911837). So I'll
> document this anyway for reference.

Kohei, I'm aware of that history.  The reason why I said we should not document this is that these are Chrome only features that we had to implement out of the fear of the Web depending on them and us having to turn them on in a rush.  Bug 911837 was reported on Nightly.  Given the fact that we never shipped this API to the Web on the release channel and that Chrome is also working on removing these non-standard APIs, I don't want us to document this code removal (which actually doesn't change what we ship to the Web) because I don't want to deal with a bunch of people reading the removal note and complaining why we're breaking websites without actually understanding what they're talking about.

Thanks for understanding, please let me know if you have any questions.
Depends on: 1021809
You need to log in before you can comment on or make changes to this bug.