Thanks for the issue...

Tried to reproduce the issue on reported chrome version 72.0.3596.0 using Mac 10.13.5. Attaching screen-cast for reference.
Steps: 
---------
1. Launched reported chrome 
2. Opened Dev tools and pasted the above given code and observed the camera focus light is on 
3. Navigated to Memory tab clicked on snapshot >> Observed the objects 
As we are not seen any errors in the objects and camera focus is on till closing the tab.

@Reporter: Could you please check the attached screen cast and please let us know if anything missed from our end and if possible provide screencast for better triaging it.

Thanks.!

Deleted: 899722.mp4 8.6 MB

	899722.mp4 8.6 MB View Download

To reiterate, if you want to attempt reproducing the issue:

1. Open Chrome or Chromium 72.0.3596 64-bit on Windows, Official or Developer Build
2. Paste and run the snippet in the Developer Tools console
3. Approve browser request to capture video and/or audio from your capture device(s)
4. Wait until the console is cleared, as that indicates the stream promise has resolved and a media recorder object was created (without references).
5. Take a heap snapshot. You can wait before doing so as much as you want -- the snapshot will contain the MediaRecorder object regardless. The latter is obviously held on to by something somewhere.
6. Observe the object on the heap by using e.g. the Summary view in Memory tab and the input field with the "Class filter" text as placeholder. There will be several objects matching MediaRecorder class name, but the one the snippet creates is the one with initialized fields, in particular a recognizeable MIME type and `stream` property referring to a stream with a valid ID, and audio/video tracks, depending on how many capture devices you have and if you allowed access to these.

Is the observed behavior by design or is it a bug? Any other object would be going out of scope, but MediaRecorder objects don't. In Firefox they do. Even running the following code (instead of the entire original snippet) has the same issue:

    new MediaRecorder(new MediaStream()); console.clear();

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

armen.michaeli@, does the heap grow with time? That shouldn't be the
case, since it's only upon start() (and some data flowing through the
MediaStreamTracks) that the encoding and buffering starts.
OTOH, MediaRecorder is linked to the MediaStreamTracks, so as long 
as they exists, MR does so too:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/mediarecorder/media_recorder.h?sq=package:chromium&dr=CSs&g=0&l=102

The heap grows with each created MediaRecorder object. No such object is ever removed from the heap (e.g. garbage collected), so if with time one creates additional MediaRecorder objects -- which is a fair possibility since each such object is "sealed" with respect to the stream and options it is created with -- then yes, the heap would grow with time.

Like I mentioned above, even creating a MediaRecorder using a stream with no tracks, like `new MediaRecorder(new MediaStream())`, puts the MediaRecorder object on the heap where it stays from then on. So this can't just be because of the track(s) being present in the stream. I have just tested this by creating a new MediaRecorder object with the latter statement every second, and with every heap snapshot I take there are just more of these objects on the heap.

mcasas@ A gentle ping..

Request you to check the update provided by the reporter in Comment #7 and help in further triaging of the issue.

Thanks..

As per comment #8, adding 'TE-NeedsTriageHelp' to remove this issue from TE triaging bucket and requesting 'Blink>MediaRecording' team to look into the issue and help further.

Thanks..