Closed
Bug 599367
Opened 14 years ago
Closed 14 years ago
can't play audio with createBlobURL
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta8+ |
People
(Reporter: amwebdk, Assigned: khuey)
References
Details
(Keywords: testcase, Whiteboard: [todo khuey comment 23])
Attachments
(2 files, 1 obsolete file)
591 bytes,
text/html
|
Details | |
176.74 KB,
patch
|
sicking
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre Build Identifier: Gecko/20100924 Firefox/4.0b7pre When i select a .oga file, and use the createBlobURL on the file object and then send the respons to "Audio.src" it can't find the file. Reproducible: Always Steps to Reproduce: 1. Select a .oga file 2. Try to play the song Actual Results: The file can't be found Expected Results: The music is playing DEMO: <!DOCTYPE html> <html> <head> <title>Audio player</title> </head> <body> <form> <input type="file" id="fileElem" multiple accept="image/*" onchange="handleFiles(this.files)"> </form> <div id="fileList"> </div> <script type="text/javascript"> function handleFiles(files) { var d = document.getElementById("fileList"); var audio = new Audio(); audio.controls = 'controls'; audio.style.height = '100px'; audio.src = window.createBlobURL(files[0]); d.appendChild(audio); } </script> </body> </html>
Reporter | ||
Updated•14 years ago
|
OS: Mac OS X → All
Hardware: x86_64 → All
Comment 1•14 years ago
|
||
Jonas, are we failing a same-origin check here or something?
blocking2.0: --- → ?
Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #1) > Jonas, are we failing a same-origin check here or something? Sorry this is my first bug report, will you please explain what you mean in an other way. As i understand it, the createBlobURL function return a "short url" string that reference to the file. I was able to use the createBlobURL function on an Image object and show an image on the screen, but when i change it to an Audio object it's looked like it could't find the file.
Comment 3•14 years ago
|
||
(In reply to comment #2) > (In reply to comment #1) > > Jonas, are we failing a same-origin check here or something? > > Sorry this is my first bug report, will you please explain what you mean in an > other way. Boris was asking Jonas (who is also CCed) a question.
We *shouldn't* be failing any same-origin checks, but I'd have to debug to figure out what's going on.
Assignee: nobody → jonas
blocking2.0: ? → beta8+
For what it's worth, please attach the testcase as an attachment instead, as to make it easier to try. Including testcases inline in comments generally is a lot less useful.
Reporter | ||
Comment 6•14 years ago
|
||
You can use this ogg file: http://audioscene.org/scene-files/humph/slideshow/Revolve.ogg
Reporter | ||
Comment 7•14 years ago
|
||
> Boris was asking Jonas (who is also CCed) a question.
I see.
I have added a testcase and a link to a ogg file.
Assignee | ||
Comment 8•14 years ago
|
||
This is complicated. I tried to track this down but there's no debugging information printed to the terminal and it's non-trivial to follow the loading process because it's all async.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 9•14 years ago
|
||
Well, for a start is anything reported to the JS console?
Assignee | ||
Comment 10•14 years ago
|
||
No, there's nothing of interest in the JS console or in the terminal (no interesting NS_ENSURE_SUCCESS failure messages)
Comment 11•14 years ago
|
||
Do we end up at least instantiating an Ogg decoder? Or do we not even get that far?
Assignee | ||
Comment 12•14 years ago
|
||
Nope, we never make it that far.
Comment 13•14 years ago
|
||
Do we get to nsMediaChannelStream::Listener::OnStartRequest? What about nsHTMLMediaElement::MediaLoadListener::OnStartRequest? What about nsHTMLMediaElement::LoadResource?
Assignee | ||
Comment 14•14 years ago
|
||
(In reply to comment #13) > Do we get to nsMediaChannelStream::Listener::OnStartRequest? No > What about nsHTMLMediaElement::MediaLoadListener::OnStartRequest? Yes > What about nsHTMLMediaElement::LoadResource? Yes
Comment 15•14 years ago
|
||
If you run Firefox with NSPR_LOG_MODULES=nsBuiltinDecoder:5,nsMediaElement:5,nsMediaElementEvents set, you'll see plenty of logging dumped to stdout. We're failing in InitializeDecoderForChannel() (called from nsHTMLMediaElement::MediaLoadListener::OnStartRequest) because the mimetype of the channel is application/octet-stream, and we're not doing type sniffing, so we fail to create a decoder.
Assignee | ||
Comment 16•14 years ago
|
||
Ah. Need to set the type then at http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsFileDataProtocolHandler.cpp#429
Assignee | ||
Comment 17•14 years ago
|
||
So setting the Content Type appropriately makes the file load and play. There is another relatively minor issue, which is that the audio controls don't get the length of the audio and treat it as an indefinite stream.
Assignee | ||
Updated•14 years ago
|
Assignee: jonas → khuey
Assignee | ||
Comment 18•14 years ago
|
||
We'll deal with the controls issue in a followup. I'll write a test for this when I have more time.
Attachment #479660 -
Flags: review?(jonas)
Comment on attachment 479660 [details] [diff] [review] Patch ># HG changeset patch ># Parent cd8b5689ffbf03423ebb8023b2fd4d09c1e941cc >diff --git a/content/base/src/nsFileDataProtocolHandler.cpp b/content/base/src/nsFileDataProtocolHandler.cpp >--- a/content/base/src/nsFileDataProtocolHandler.cpp >+++ b/content/base/src/nsFileDataProtocolHandler.cpp >@@ -426,8 +426,16 @@ nsFileDataProtocolHandler::NewChannel(ns > > nsCOMPtr<nsISupports> owner = do_QueryInterface(info->mPrincipal); > >+ nsAutoString type; >+ nsCAutoString narrowtype; >+ rv = info->mFile->GetType(type); >+ NS_ENSURE_SUCCESS(rv, rv); >+ >+ CopyUTF16toUTF8(type, narrowtype); >+ > channel->SetOwner(owner); > channel->SetOriginalURI(uri); >+ channel->SetContentType(narrowtype); > channel.forget(result); Nit: Use channel->SetContentType(NS_ConvertUTF16toUTF8(type)); r=me with that.
Attachment #479660 -
Flags: review?(jonas) → review+
Assignee | ||
Comment 20•14 years ago
|
||
Nit fixed. Asking for a once over on the test changes too.
Attachment #479660 -
Attachment is obsolete: true
Attachment #480312 -
Flags: review?(jonas)
Attachment #480312 -
Flags: review?(jonas) → review+
Reporter | ||
Comment 21•14 years ago
|
||
Mayby it would be relevant to include <video>, <object> and <embed> in the testcase
Reporter | ||
Comment 22•14 years ago
|
||
Sorry, misspelling "Maybe it would be relevant to include <video>, <object> and <embed> in the testcase".
Assignee | ||
Comment 23•14 years ago
|
||
Video and audio use the same codepath, though it wouldn't hurt to add a test for that. <object> and <embed> might not work even with this ... suppose I should test that.
Assignee | ||
Updated•14 years ago
|
Component: Video/Audio → DOM
QA Contact: video.audio → general
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Whiteboard: [todo khuey comment 23]
Assignee | ||
Updated•14 years ago
|
Whiteboard: [todo khuey comment 23] → [todo khuey comment 23][ready to land]
Assignee | ||
Comment 24•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/a0699cc12503
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [todo khuey comment 23][ready to land] → [todo khuey comment 23]
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•