MediaRecorder: fire onError if the amount of tracks of the MediaStream varies

third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp

Index: third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp
diff --git a/third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp b/third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp
index 9713746b3413c61ba99626773af403ac7249b3eb..0b74eaf620a59c8fbcb81f8b07528f6dff67c164 100644
--- a/third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp
+++ b/third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp
@@ -55,6 +55,7 @@ MediaRecorder* MediaRecorder::create(ExecutionContext* context, MediaStream* str
 MediaRecorder::MediaRecorder(ExecutionContext* context, MediaStream* stream, const MediaRecorderOptions& options, ExceptionState& exceptionState)
     : ActiveDOMObject(context)
     , m_stream(stream)
+    , m_streamAmountOfTracks(stream->getTracks().size())
     , m_mimeType(options.mimeType())
     , m_stopped(true)
     , m_ignoreMutedMedia(true)
@@ -205,6 +206,8 @@ void MediaRecorder::writeData(const char* data, size_t length, bool lastInSlice)
         m_stopped = false;
         scheduleDispatchEvent(Event::create(EventTypeNames::start));
     }
+    if (m_stream && m_streamAmountOfTracks != m_stream->getTracks().size())
+        onError("Amount of tracks in MediaStream has changed.");

[Peter Beverloo, 2016/01/13 18:38:01]

This fires an `onerror` event each time writeData() is called after the number
of tracks has changed. There's also the case where a track was removed, and
another track was added - today that would mute the error again.

How useful are the repeated `onerror` events if we don't stop the recording? In
most APIs, receiving an `onerror` event means that the functionality stops (i.e.
notifications or XHR).

[Peter Beverloo, 2016/01/13 18:38:01]

Will you address the specification bug?

[mcasas, 2016/01/13 21:50:41]

Acknowledged.

[mcasas, 2016/01/13 21:50:41]

Yes, I should update m_streamAmountOfTracks after the
first error is fired. Done. 
So I was thinking about it, and wrote in the CL description,
that what would be the best way to proceed towards the
user  when a Track is added or Removed, since anyway 
the content would not be recorded/ sotp being recorded,
respectively, automatically? I think the MR should keep
recording whatever it has and let the JS decide what's the
appropriate course of action. The Spec is quite fuzzy 
about it, and it only mentions a DOMException in case
Tracks are added or removed... which can't be since is
an asynchronous condition. Like you say below, the Spec
should be updated (which falls on me again!)

So the point of this CL is to, at least, fire an Error if 
something like this happen...

 
     // TODO(mcasas): Act as |m_ignoredMutedMedia| instructs if |m_stream| track(s) is in muted() state.
 
@@ -225,9 +228,6 @@ void MediaRecorder::onError(const WebString& message)
 {
     // TODO(mcasas): Beef up the Error Event and add the |message|, see https://github.com/w3c/mediacapture-record/issues/31
     scheduleDispatchEvent(Event::create(EventTypeNames::error));
-
-    if (m_state == State::Recording)
-        stopRecording();
 }
 
 void MediaRecorder::createBlobEvent(Blob* blob)