Closed Bug 863254 Opened 12 years ago Closed 12 years ago

ArrayBuffer returns null when you load an ogg file with xhr

Categories

(Core :: JavaScript Engine, defect)

21 Branch
All
macOS
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: dennis, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:23.0) Gecko/20130417 Firefox/23.0 Build ID: 20130417031053 Steps to reproduce: var request = new XMLHttpRequest(); request.open('GET', 'file.ogg', true); request.responseType = 'arraybuffer'; request.addEventListener('load', function( e ) { console.log(request.response); }, false ); request.send(); Actual results: Returns an empty ArrayBuffer {}. the returned file.ogg source is empt Expected results: Return chunked ogg data
Version: 23 Branch → 21 Branch
Reproducible on the latest Firefox 23 Nightly - I get the empty array on Mac OSX 10.8.2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Component: JavaScript Engine → Video/Audio
Component: Video/Audio → JavaScript Engine
Dennis, Ioana, which testcase are you using here, exactly? The behavior of the script in comment 0 depends on what happens when the load of file.ogg happens, obviously. Can you please link to an actual page showing the problem? Also, is this about 21 or 23? All the UA strings in this bug are 23....
Flags: needinfo?(ioana.budnar)
Flags: needinfo?(dennis)
What I used was the code in comment 0 in the web console. The ogg file that I used is this one: http://videos.mozilla.org/firefox4beta/Firefox_4_beta.theora.ogv.
Flags: needinfo?(ioana.budnar)
Hi Boris, Here you can find a real test case (works in Chorme): http://pluxbox.com/pluxbox_com/arraybuffer/simple-dash-fragment.html I use Firefox 21 Nightly If you need more information let me know.
Flags: needinfo?(dennis)
> What I used was the code in comment 0 in the web console. With the web console open to which site? I tried putting that code into an actual HTML file that links to the .ogg. For now you can see the result at http://web.mit.edu/bzbarsky/www/test-arraybuffer-xhr.html and it seems to work just fine in both a nightly and a beta 21 build, as far as I can tell. > http://pluxbox.com/pluxbox_com/arraybuffer/simple-dash-fragment.html This is doing an XHR to a page that's 404. Is that expected? In any case, using that testcase but running the script in the console so I can examine the byteLength of the array, I see a byteLength of 19762 in both Firefox and Chrome. Am I just missing something? What are the actual steps to reproduce the bug? > I use Firefox 21 Nightly Firefox 21 is in beta right now. Nightly is Firefox 23....
Flags: needinfo?(ioana.budnar)
Flags: needinfo?(dennis)
First a correction to comment 3: I used the Firebug console, not the web console. I just opened http://videos.mozilla.org/firefox4beta/Firefox_4_beta.theora.ogv and about:home in new tabs and ran that code with the ogv link instead of file.ogg on them.
Flags: needinfo?(ioana.budnar)
Well, about:home certainly can't do an XHR to videos.mozilla.org, since that would be a cross-site load....
I made a little mistake in my c/p action. I renamed the ogg file to 'file.ogg' but still get the same problem in 21 (beta ;-)) : > http://pluxbox.com/pluxbox_com/arraybuffer/simple-dash-fragment.html
Flags: needinfo?(dennis)
OK. So if I take a current Firefox 21 beta and load http://pluxbox.com/pluxbox_com/arraybuffer/simple-dash-fragment.html then my web console says: [04:10:17.029] bufferArray [object ArrayBuffer] byteLength 89177 Do you see something else? If so, what? Just to check, do you see your problem in safe mode?
Yes, open: > http://pluxbox.com/pluxbox_com/arraybuffer/simple-dash-fragment.html In Firefox ArrayBuffer {} simple...nt.html (line 25) And in Google Chrome: ArrayBuffer {byteLength: 89177, slice: function} simple-dash-fragment.html:25 If you open the link in the firebug concole to the file.ogg you can see the the link returns NULL. If you open the link in a new tab you can hear the file excist If you remove the "responseType" it response binairy data
Its hard to reproduce the bug in save mode because I dont have Firebug. The Firefox webconsole don't shows the file.ogg xhr request :S
Wait. Stop. Back up. Is the complaint about the _actual_ data that's returned, or about how the firebug console is showing things to you? Because as I said, for me the console.log in the testcase shows an ArrayBuffer object with the right byteLength. But the things you're showing in comment 10 look nothing like the console.log call in the testcase, so I'm not sure where you're getting those from exactly. So again, can I have clear steps to reproduce, including clear expected results and clear actual results, to make sure I'm looking at the same thing you're looking at? > The Firefox webconsole don't shows the file.ogg xhr request :S Shows it fine for me....
What a day! According to some research, I conclude that the array buffer works well. I'm working on an implementation of the Web Audio API. The error message I got was the same as when I tried to download a file that doesn't exist. I now know that the createBuffer isn't realy implemented yet (848652) so I changed it to decodeAudioData. It works!! I will really super thank you for your patience and support! Dennis
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You're welcome. Thanks for sticking with this!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: