896371 - Media Recording - Can't record the mediaStream from audio tag with src=local file

Status: NEW

(Core :: Audio/Video: Recording, defect, P3)

Description

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Found the principle check should be equal.

nsPrincipal::Subsumes(nsIPrincipal *aOther, bool *aResult)
{
  return Equals(aOther, aResult);
}
The mediaStream's principal has the "file" targetScheme and MediaRecorder's document's principal fail to subsumes with the mediaStream's principal.

Comment 1

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Test page: 
http://people.mozilla.org/~rlin/record_audiotag.html

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What is this bug about? I don't understand.

Comment 3

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

I try to record the mediastream which come from an audio tag, if the src is a file, I found the principal check is failed. Seems it can't compare with two different schema.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http: URLs aren't same-origin with file: URLs, if that's what you mean.

The example in comment #1 works I think, since the page and the OGG file are both http URLs.

Comment 5

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

roc, you are right.
This problem happen on open the local html file and do the record function.
So that cause this problem.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not sure if this is a real bug, but even if it is, it's not very important since file URLs are not very much used.

Comment 7

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi roc, 
But the test case will failed due to this problem..

Comment 8

[Jason Smith [:jsmith]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> I'm not sure if this is a real bug, but even if it is, it's not very
> important since file URLs are not very much used.

The mochitests in content/media however rely on file:/// protocol URLs however on desktop. So this bug will become a problem in mochitests. However, The other option we could do here is to workaround the problem in manifest.js similar to what's done on Android and B2G to avoid file:/// protocol URLs for media recorder mochitests.

Reference:

http://mxr.mozilla.org/mozilla-central/source/content/media/test/manifest.js#217

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Only gInfoLeakTests uses fileUriToSrc, and gInfoLeakTests has nothing to do with Media Recorder. So I don't see what test case is going to fail.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #9)
> Only gInfoLeakTests uses fileUriToSrc, and gInfoLeakTests has nothing to do
> with Media Recorder. So I don't see what test case is going to fail.

Ah you are right. Hmm...well, apparently this is going to fail with a mochitest URL loaded over HTTP. I just modified my patch on the blocking bug to directly load the opus resource over HTTP and I still get this security error.

https://tbpl.mozilla.org/?tree=Try&rev=fd385252fac9

https://hg.mozilla.org/try/rev/fd385252fac9#l2.27

So the open question here is why are we getting a security error when loading a media resource over HTTP as well?

Comment 12

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Use this kind of format shouldn't be blocked. 
    2.27 +  var baseURL = 'http://mochi.test:8888/tests/content/media/test/';
    2.29 +  element.src = baseURL + test.name;
I will check it.

Comment 13

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Attachment: test_mediarecorder_recordnotimeslice.html

That securityError cause by the principal object is created by the decoder object and MediaRecorder will use it to check if this UA can record this object. So the mediaRecorder start should wait the audio element's decoder ready.

Maybe hook the ready event(or others one?) on audio tag then start test is better than my method.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Randy Lin [:rlin] from comment #13)
> Created attachment 783236 [details]
> test_mediarecorder_recordnotimeslice.html
> 
> That securityError cause by the principal object is created by the decoder
> object and MediaRecorder will use it to check if this UA can record this
> object. So the mediaRecorder start should wait the audio element's decoder
> ready.
> 
> Maybe hook the ready event(or others one?) on audio tag then start test is
> better than my method.

Ah ha. That makes sense. Probably need to wait until canplaythrough fires then before calling start on the media recorder object.

Comment 15

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> I'm not sure if this is a real bug, but even if it is, it's not very
> important since file URLs are not very much used.

It looks like web apps installed on b2g use file URLs too. For that case, it will stop web apps from working on b2g.

Comment 16

[Jason Smith [:jsmith]]

(In reply to jwwang from comment #15)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> > I'm not sure if this is a real bug, but even if it is, it's not very
> > important since file URLs are not very much used.
> 
> It looks like web apps installed on b2g use file URLs too. For that case, it
> will stop web apps from working on b2g.

So the device storage use case could be potentially be impacted then, right?

Comment 17

[Jason Smith [:jsmith]]

This might even impact packaged apps generally. I'm putting needinfo on myself to test this in a packaged app. If it does, then probably needs a blocker for release.

Comment 18

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #17)
> This might even impact packaged apps generally. I'm putting needinfo on
> myself to test this in a packaged app. If it does, then probably needs a
> blocker for release.

This appears to work fine for me in a packaged app I created here:

http://mozilla.github.io/qa-testcase-data/webapi/mediarecorder/mediaRecorder.zip

I'm not seeing the error seen in this bug in a packaged app making use of an opus file local to the packaged app.

Comment 19

[JW Wang [:jwwang] [:jw_wang]]

It looks like packaged app will use app:// scheme instead of file://. So it won't have the same-origin problem as local files.

Comment 20

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Free this if anyone wants.

Comment 21

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.