Steps: Load https://developers.google.com/events/io/ Results: Only "g +1" button is displayed These appear in "Error Console": Timestamp: 4/12/2013 9:19:30 AM Error: The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol. Source File: https://developers.google.com/events/io/ Line: 0 Timestamp: 4/12/2013 9:19:33 AM Error: The buffer passed to decodeAudioData contains an unknown content type. Source File: https://developers.google.com/events/io/ Line: 0 Timestamp: 4/12/2013 9:19:33 AM Error: The buffer passed to decodeAudioData contains an unknown content type. Source File: https://developers.google.com/events/io/ Line: 0 Expected results: Page loads correctly Other browsers: Page works on Internet Explorer 8 Tested configuration: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:23.0) Gecko/20130412 Firefox/23.0 ID:20130412030828 CSet: 7b8ed29c6bc0 Initial report: http://forums.mozillazine.org/viewtopic.php?p=12789179#p12789179
The page displays correctly in Firefox 19.0.2, Firefox 20, IE 10, Chrome 26.0.1410.43 m, and Chrome 26.0.1410.64 m. The main canvas does not show up in the 12 April 2013 Nightly 23.0a1 in a new profile (normal or safe mode).
Regression pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4a54cc0f7c36&tochange=6922ed98876a Triggered by: 6922ed98876a Ehsan Akhgari — Bug 851603 - Enable Web Audio in Nightly; r=roc
It seems like this website is trying to use decodeAudioData to decode https://developers.google.com/events/io/sounds/home/i.mp3 and https://developers.google.com/events/io/sounds/home/o.mp3, which will not work if the browser doesn't support decoding MP3 data, and fails to handle the failure case (they don't pass a failure callback to decodeAudioData at all.) Not sure if there is anything on our side to do about this. I will contact the Google folks.
This doesn't work in Nightly on Windows 7, which does support MP3 decoding, because our sniffer (nsMediaSniffer.cpp) detects MP3 by looking for the magic bytes "ID3" at the start of the file, and this fails on https://developers.google.com/events/io/sounds/home/o.mp3 which doesn't have those bytes.
The url is served with the correct mimetype: $ curl --head https://developers.google.com/events/io/sounds/home/i.mp3 HTTP/1.1 200 OK Content-Language: en X-Content-Type-Options: nosniff Vary: Accept-Language, Cookie Last-Modified: Fri, 12 Apr 2013 23:05:18 GMT X-Frame-Options: SAMEORIGIN Content-Type: audio/mpeg Content-Length: 13440 Date: Mon, 15 Apr 2013 21:36:29 GMT Server: Google Frontend However, WebAudio's decodeAudioData method provides no 'type' argument which could be used to pass this in and therefore appears to require sniffing. :-( http://mimesniff.spec.whatwg.org/#matching-an-audio-or-video-type-pattern only identifies mp3 streams with ID3 tags, because untagged mp3 stream identification requires more than the 500 byte budget the spec was aiming for. I propose we implement raw mp3 detection based on looking for a second capture pattern at the expected offset after the first packet in nsMediaSniffer and using that. Then advocate adding it to the general mime-sniffing documents.
This is an evangelism bug. Per irc I've opened bug 862088 to see what we can do to address this on our side technically.
There's nothing actionable to track on this for FF22 in terms of evangelism - Google I/O will have come and gone before FF22 is shipped - and bug 862088 can track the longer-term fix proposal which could be nominated for uplift if low risk enough and early in an aurora/beta cycle.
The WebAudio spec says "Audio file data can be in any of the formats supported by the audio element." So google should be checking audio.canPlayType('audio/mpeg') instead of just assuming the presence of WebAudio implies mp3 decoder support. This is something we should raise with them as a standards issue regardless of the status of the implementation in Nightly.
(In reply to comment #8) > The WebAudio spec says "Audio file data can be in any of the formats supported > by the audio element." So google should be checking > audio.canPlayType('audio/mpeg') instead of just assuming the presence of > WebAudio implies mp3 decoder support. > > This is something we should raise with them as a standards issue regardless of > the status of the implementation in Nightly. Yes, I've done that this morning.
This is fixed now.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.