New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users
Status: Archived
Owner:
Closed: Aug 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression

Blocking:
issue 402007



Sign in to add a comment
Deprecated AudioContext methods have been removed
Reported by jasonkes...@gmail.com, Jul 18 2014 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Example URL:
http://www.expatsoftware.com/test/audiocontext_issue.html

Steps to reproduce the problem:
Call a deprecated method on an AudioContext object, such as createGainNode() or noteOn()

What is the expected behavior?
Method functions as per the standard

What went wrong?
These methods have been removed in Chrome 36

Did this work before? Yes Chrome 35 and earlier

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes 

Chrome version: 36.0.1985.125  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

The new AudioContext method names only date back to 2012, so software written before then will all be broken.  

Our company, for example, produces a tool that allows users to author HTML5 content that includes audio.  Customers who purchased this tool just two years ago will have all the content they've created with it suddenly break as a result of this change. 

Deprecated methods should not be removed from the browser before software vendors have had plenty of time to update.  Two years is not "plenty".  Consider the case of Internet Explorer, which still supports document.all fifteen years after it was deprecated in favor of document.getElementById().  Consider also the example of Java classes that remain deprecated since the 1990s.  That is the expectation that developers have of "deprecated" methods.

Leaving these methods in place causes no harm.  Removing them causes quite a bit of harm.

Please reintroduce them as aliases to the new methods.
 
jasonkester: Can you describe what the example URL is demonstrating? I found that both links did nothing. I checked in Firefox as well.
Labels: Needs-Feedback
@ajnol

On the original poster's link, you should see 2 different hyperlinks.  One for Old Style and one for New Style.

If you click on New Style in Chrome 36, you'll hear a beep.  If you click on Old Style in Chrome 36, you'll hear nothing and you'll get this error in the console:

Uncaught SyntaxError: Failed to construct 'AudioContext': number of hardware contexts reached maximum (6). audiocontext_issue.html:9
oldStyle audiocontext_issue.html:9
(anonymous function)

=====================================

Both the New and Old Style links would play a sound in Chrome 35.  
Understood on how it should function, however, I hear no beeps with either link in Chrome or Firefox. Also IE, for that matter. 
Comment 5 by tkent@chromium.org, Jul 22 2014
Labels: -Cr-Internals-Media Cr-Blink-WebAudio
If you have the latest version of Chrome stable installed, you'll hear a beep when you click on New Style.

IE doesn't support the Web Audio API.  It won't work there.  Not sure about Firefox.  Their implementation of HTML5 has always been sketchy.


Labels: -Type-Bug -Needs-Feedback Type-Bug-Regression
Status: Untriaged
Able to reproduce the issue on 36.0.1985.125 stable and latest canary 38.0 2106.0.

Regression bug broken in M36, between 36.0.1930.0 and 36.0.1931.0. 
Working on bisect.
Labels: M-36
Owner: m...@chromium.org
Status: Assigned
Good build: 36.0.1930.0
bad build: 36.0.1931.0
Chrome build CL is http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=262355:262250&mode=html

Suspecting 262304.
miu@, would you mind take a look at this issue.
Please feel free to revert, if this is not related to your change.

The change in question can be found here:

http://src.chromium.org/viewvc/blink?view=revision&revision=170985

http://src.chromium.org/viewvc/blink/trunk/Source/modules/webaudio/AudioBufferSourceNode.cpp?view=log

Revert that revision and you'll fix several thousand broken web pages.


For a comical side note, Chrome developers noticed that this broke a high profile site during testing (Angry Birds HTML5 version), and rather than take this as a sign that maybe removing these methods was a bad idea, decided instead to wait one release so that they could fix the site in question:

https://code.google.com/p/chromium/issues/detail?id=358398



Comment 10 by m...@chromium.org, Jul 31 2014
Labels: -OS-Windows OS-All
Owner: rtoy@chromium.org
Has nothing at all to do with my change.  Looks like rtoy@ was working on this.
Comment 11 by rtoy@chromium.org, Jul 31 2014
Yes, the old methods that are not part of the WebAudio spec have been removed. This is intentional.

For more information and a temporary solution, see http://updates.html5rocks.com/2014/07/Web-Audio-Changes-in-m36.

Of course, if you use the new methods, your app should also work with Firefox. Presumably, if IE implemented WebAudio, they would not use the old methods either.
@rtoy I think you misunderstand the issue.

The code that is breaking is not under our control.  It is not even under our customers' control anymore.  This is breaking for presentations and learning materials generated by our customers and delivered to *their* customers.  And to be clear, when those customers generated this content, there was no new interface, and the methods in question had not been deprecated.

It's not just us, by the way.  We are a large software company to be sure, but this is also very embarrassing for Adobe, which has a similar product on the market that produced output for their customers who are now facing a lot of anger from *their* customers.

http://blogs.adobe.com/captivate/2014/07/update-on-captivate-html-5-content-playback-issue-in-google-chrome-browser.html

In short, regardless of the fact that this was intentional, it was very short sighted and a bad idea.

It needs to be reverted.
Comment 13 by rtoy@chromium.org, Jul 31 2014
Cc: cwilso@chromium.org
The code you refer to is not standard.  For example, it will not work in Firefox's standards-compliant implementation.  The "standard" you're referring to is also a draft specification (even now), not even a Candidate Recommendation; but the usage in question is using a webkit-prefixed version of the API, making it even less standardized.

Yes, this causes some short-term pain, as developers need to revisit code that they wrote to an early draft standard, supported by only one implementation under a proprietary prefix.  On the other hand, the benefit is that developers' code will then work across multiple implementations, not unfairly penalizing any other browsers for properly implementing the standards.  When IE ships their implementation, for example, your code should just work.

If two years is not enough time to make changes to your web app implementation, you REALLY should not be writing code based on experimental features that are not finalized standards.  Until Web Audio becomes a Recommendation, it is possible it will change.  Over time, of course, potential changes must become less impactful to backwards compatibility; but those changes were made for a reason, driven by the consensus of the group developing the standard.

I would strongly recommend looking at the webkitAudioContext monkey patch I wrote (https://github.com/cwilso/webkitAudioContext-MonkeyPatch) as a temporary solution.  Reverting these changes that improve the standardization of the web platform, however, would be a grave mistake, and extremely short sighted, trading a short term easement for a long term mess.

(Incidentally, using Internet Explorer as a good example of how deprecation should be done is probably not very appropriate; and I say that having spent fifteen years working on the IE team.  That approach has caused countless problems and lost person-years of productivity.)
Again, you write under the assumption that we have control over the code in question.  That is not the case in our or Adobe's position.  These are tools which non-technical users can use to produce HTML5 output.  They shipped with browser-switched versions of the API as it stood one year ago.  

As you are no doubt aware, there is no unshipping shipped software.  We can (and have) release patches so that new content generated by our customers won't have these issues.  We can't do anything about the packages they've shipped to their clients.

Regardless, this feature removal sets a new precedent.  Developers have come to expect that features in a browser will remain there.  You'll notice that the "FRAME" tag is currently deprecated and has been for several years.  You have not removed it from Chrome, for good reason.  Were you to do so, you would break a substantial portion of the internet.

That's essentially what you've done with release 36.  Only the portion of the internet you've broken is much smaller.

I'd ask that this issue be moved up the chain a few notches, so that it can be deliberated over by somebody with a vested interest in the browser as a whole.  Looking at the change log, it seems the feature was removed at the whim of a single developer, without any directive to make the change in question.  That seems, from the outside, to be an odd way to run a product.

I'd recommend that the feature be put back in place, and more careful consideration be taken if it again is recommended for removal.
Comment 16 by rtoy@chromium.org, Aug 4 2014
I can assure you it was not done on the whim of a developer and had approval from the appropriate people.

If you wish to escalate this issue, it's probably best to bring this up on the chromium dev email list.
Comment 17 by rtoy@chromium.org, Aug 8 2014
Blocking: chromium:402007
Status: Archived
Slated to an old branch and no activity in the bug in over a year suggest that this can be archived.
Sign in to add a comment