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.

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

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

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.

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.

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

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.

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

(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

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.

(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?

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.

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.

(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.

(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.

(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?

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.

(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.

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

Free this if anyone wants.

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