wolenetz/servolk: I haven't looked at this code before.  Can the assert just be removed?  Or does something actually need fixing here?

Removing that assert is probably unnecessary. Can we change our tests to either:
1. Not call URL.createObjectURL twice - can we just make sure we set the source only once? IMHO it would be the best/cleanest solution.
2. If we really need to set the source twice, can you try calling  URL.revokeObjectURL before calling URL.createObjectURL for the second time? That should release all the resources associated with the previous invocation, and so there should be no assert after that, I think.

Actually I have no idea where the js code is (somewhere in MPL ... ?), but I expect we could fix the test, sure.

Having said that, an assert indicates the application has got into an invalid/unexpected state, and it shouldn't be possible to do that through JS APIs.  Either the assert is wrong (and can be removed), or it is indicating a bug in this code.  Either way, we should have a fix at this level also.

TBH I'm not super familiar with that code myself, but I suspect calling createObjectURL twice in a row without calling .revokeObjectURL might cause internal memory leaks and assert is there to draw attention to that. So on one hand the assert seems somewhat justified for now, on the other hand, perhaps we could do the .revokeObjectURL automatically when we detect the second .createObjectURL call, if that's not against the MSE spec.
+kouhei@ who added the code where assert is tripping, +philipj@ for general blink MSE advice.

This looks like a bug. Calling URL.createObjectURL(x) multiple times if x is a Blob or MediaStream does not assert in my testing.

It looks like MediaSource::m_isAddedToRegistry is only used for hasPendingActivity() to keep it alive, and a quickfix would be to use a counter instead of a bool.

That probably isn't the ideal fix, though, and it would be good to look into why MediaStream doesn't need to keep track of the same thing. It could be that MediaStream objects can get GC'd when they shouldn't, or perhaps something else keeps them alive.

Ok, this is still blocking our tests so I went and looked a bit deeper. The difference between MediaStream and MediaSource is that MediaSource is ActiveScriptWrappable so it needs to implement a hasPendingActivity method (which tells GC whether we need to keep this object alive).
MediaStream, on the other hand, doesn't directly implement ActiveScriptWrappable and is kept alive by associated MediaStreamTrack which implements ActiveScriptWrappable. So I think converting the MediaSource::m_isAddedToRegistry into a counter should be fine.

@#6 that SGTM. I'm CR'ing your associated fix (https://codereview.chromium.org/2133143003/) at the moment. Thanks to foolip@ and servolk@ for fixing this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/014758724726a61d5a54df88e4fe993436a17442

commit 014758724726a61d5a54df88e4fe993436a17442
Author: servolk <servolk@chromium.org>
Date: Wed Jul 13 01:37:55 2016

Allow multiple URL.createObjectURL invocations for MediaSource

Currently calling URL.createObjectURL for a MediaSource more than once
causes an assert/crash due to MediaSource::m_isAddedToRegistry flag
being already set. But since calling createObjectURL is actually a
valid thing to do and should just generate new unique URLs, let's
replace the m_isAddedToRegistry flag with a counter.

BUG= 604425 

Review-Url: https://codereview.chromium.org/2133143003
Cr-Commit-Position: refs/heads/master@{#404879}

[modify] https://crrev.com/014758724726a61d5a54df88e4fe993436a17442/third_party/WebKit/LayoutTests/http/tests/media/media-source/mediasource-multiple-attach.html
[modify] https://crrev.com/014758724726a61d5a54df88e4fe993436a17442/third_party/WebKit/Source/modules/mediasource/MediaSource.cpp
[modify] https://crrev.com/014758724726a61d5a54df88e4fe993436a17442/third_party/WebKit/Source/modules/mediasource/MediaSource.h