861187 - https://developers.google.com/events/io/ is mostly blank on Nightly

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[alex_mayorga]

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

Comment 1

[B.J. Herbison]

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).

Comment 2

[Alice0775 White]

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

Comment 3

[(no longer active)]

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.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

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.

Comment 5

[Ralph Giles (:rillian)]

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.

Comment 6

[Ralph Giles (:rillian)]

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.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 8

[Ralph Giles (:rillian)]

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.

Comment 9

[(no longer active)]

(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.

Comment 10

[Ralph Giles (:rillian)]

Great, thanks!

Comment 12

[(no longer active)]

This is fixed now.