Bug 1127188 - Properly handle AudioContext.close() calls right after the creation of an AudioContext. r=ehsan

When the underlying audio stream platform is slow to start, it can take a little
while for the AudioContext to switch from its initial "suspended" state to
"running".

Authors can call AudioContext.close() right after (new AudioContext()),
that was resulting in a bogus "closed" -> "running" transition, that is now
handled properly by bailing out: the context will simply not report a switch to
"running".

dom/media/test/crashtests/1127188.html

@@ -0,0 +1,3 @@
+<script>
+  (new AudioContext).close();
+</script>

dom/media/test/crashtests/crashtests.list

@@ -78,6 +78,7 @@ load 1080986.html
 load 1158427.html
 load 1157994.html
 load 1122218.html
+load 1127188.html
 include ../../mediasource/test/crashtests/crashtests.list
 
 # This needs to run at the end to avoid leaking busted state into other tests.

dom/media/webaudio/AudioContext.cpp

@@ -769,13 +769,19 @@ private:
   nsRefPtr<AudioContext> mAudioContext;
 };
 
-
-
 void
 AudioContext::OnStateChanged(void* aPromise, AudioContextState aNewState)
 {
   MOZ_ASSERT(NS_IsMainThread());
 
+  // This can happen if close() was called right after creating the
+  // AudioContext, before the context has switched to "running".
+  if (mAudioContextState == AudioContextState::Closed &&
+      aNewState == AudioContextState::Running &&
+      !aPromise) {
+    return;
+  }
+
   MOZ_ASSERT((mAudioContextState == AudioContextState::Suspended &&
               aNewState == AudioContextState::Running)   ||
              (mAudioContextState == AudioContextState::Running   &&