Created attachment 808026 [details] testcase 1. Run a debug build with XPCOM_MEM_LEAK_LOG=2 2. Load the testcase 3. Quit Result: trace-refcnt reports leaked MediaStream and other objects.
The Media Recorder get the media stream object without tracks and enter recording state. I will fix it.
FWIW - this is good candidate to get a mochitest with btw. You could just create a test that models the exact test case included with an additional check that the InvalidStateError fires when calling start a 2nd time.
I will let media recorder throw the InvalidStateError exception when we got this kind of source. BTW, correct the comment 2, now it failed on principal check (no source can be checked) and throw security error without destroy the TrackUnionStream object, this unclear message would confuse UA.
Created attachment 809795 [details] [diff] [review] patch v1 patch for this bug, also include the test case.
Created attachment 811036 [details] [diff] [review] check-in patch Check in patch, carry reviewer, merge with today's mc change. try result https://tbpl.mozilla.org/?tree=Try&rev=13fbf4296439
Created attachment 811037 [details] [diff] [review] check-in patch this one, remove two useless header include.
Verified through successful landing of mochitest.
bug 924724, which is koi+, depends on the change here. Need to uplift this patch
(In reply to C.J. Ku[:CJKu] from comment #12) > bug 924724, which is koi+, depends on the change here. Need to uplift this > patch That shouldn't influence if this bug is a blocker or not. What you need to do on bug 924724 is build a branch-specific patch to fix the issue independent of this bug. I don't think this bug is a blocker either - it's not a likely use case a developer will do & memory leak impact isn't critical.
If the branch-specific patch ends up being "roll these changes into that patch", it would be preferable to just land these changes under this bug number. Also, we have a lot of historical precedent for "blocks a blocker" approvals.