Closed Bug 861187 Opened 11 years ago Closed 11 years ago

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

Categories

(Tech Evangelism Graveyard :: English US, defect)

x86
All
defect
Not set
normal

Tracking

(firefox21 unaffected, firefox22-, firefox23-)

RESOLVED FIXED
Tracking Status
firefox21 --- unaffected
firefox22 - ---
firefox23 - ---

People

(Reporter: alex_mayorga, Assigned: ehsan.akhgari)

References

()

Details

(Keywords: regression)

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).
Keywords: regression
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
Blocks: 851603
Component: Untriaged → Video/Audio
Product: Firefox → Core
Version: Trunk → 22 Branch
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.
Assignee: nobody → english-us
Blocks: webaudio
No longer blocks: 851603
Component: Video/Audio → English US
Product: Core → Tech Evangelism
Version: 22 Branch → Trunk
Assignee: english-us → ehsan
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.
Great, thanks!
OS: Windows 7 → All
This is fixed now.
Status: NEW → RESOLVED
Closed: 11 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.