Closed Bug 599367 Opened 14 years ago Closed 14 years ago

can't play audio with createBlobURL

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

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)

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>
OS: Mac OS X → All
Hardware: x86_64 → All
Jonas, are we failing a same-origin check here or something?
blocking2.0: --- → ?
(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.
(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.
> Boris was asking Jonas (who is also CCed) a question.
I see.

I have added a testcase and a link to a ogg file.
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
Well, for a start is anything reported to the JS console?
No, there's nothing of interest in the JS console or in the terminal (no interesting NS_ENSURE_SUCCESS failure messages)
Do we end up at least instantiating an Ogg decoder?  Or do we not even get that far?
Nope, we never make it that far.
Do we get to nsMediaChannelStream::Listener::OnStartRequest?

What about nsHTMLMediaElement::MediaLoadListener::OnStartRequest?

What about nsHTMLMediaElement::LoadResource?
(In reply to comment #13)
> Do we get to nsMediaChannelStream::Listener::OnStartRequest?
No
> What about nsHTMLMediaElement::MediaLoadListener::OnStartRequest?
Yes
> What about nsHTMLMediaElement::LoadResource?
Yes
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.
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: jonas → khuey
Attached patch Patch (obsolete) — Splinter Review
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+
Attached patch Patch w/testSplinter Review
Nit fixed.  Asking for a once over on the test changes too.
Attachment #479660 - Attachment is obsolete: true
Attachment #480312 - Flags: review?(jonas)
Mayby it would be relevant to include <video>, <object> and <embed> in the testcase
Sorry, misspelling "Maybe it would be relevant to include <video>, <object> and <embed> in the
testcase".
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.
Component: Video/Audio → DOM
QA Contact: video.audio → general
Keywords: checkin-needed
Whiteboard: [todo khuey comment 23]
Whiteboard: [todo khuey comment 23] → [todo khuey comment 23][ready to land]
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]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: