Note to web authors that might be hitting this MSE bug: please await "loadedmetadata" before making any track selection/enabled changes. This will likely be the most interoperable way forward with MSE v1 and Chrome's current implementation until this bug is fixed.

Similarly, HAVE_METADATA and 'loadedmetadata' may occur some short time after 'updateend' for the append of the first initialization segment. Awaiting both events will ensure that the initialization segment received algorithm has fully completed.

(This is an implementation bug, but has a reasonable IMHO workaround.)

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

commit 008f8daf59e8d74ea3bf5a27e7d5d3ae9132c4bd
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Thu Aug 10 17:32:12 2017

MSE: Fix 2 causes of mediasource-duration.html test flakiness

This change makes the test less prone to flakiness for a couple cases:

1) One test case didn't await 'loadedmetadata' from mediaElement (or any
   other mediaElement event indicating it had reached a readyState >=
   HAVE_METADATA) before asserting that the mediaElement had a valid
   duration. Bug 641121 tracks fixing the implementation to ensure
   HAVE_METADATA is reached before 'updateend' is signalled for an
   appendBuffer that triggered the initialization segment received
   algorithm for the last SourceBuffer that previously hadn't received
   an init segment yet. Example flaky failure previously:
      Test duration reduction below highest buffered presentation time
      is disallowed assert_equals: mediaElement duration matches
      fullDuration expected 6.042 but got NaN

2) Multiple test cases used a common utility which (correctly) expected
   a 'timeupdate' event between 'seeking' and 'seeked'. The test
   expectation manager would thus expect 'timeupdate' to occur *only*
   between those two other events; 'timeupdate' could actually also
   occur prior to 'seeking'. This change introduces an extra
   'waitForExpectedEvents' between that utility's 'seeking' and
   'timeupdate' expectations to let the utility ignore any 'timeupdate'
   which might occur prior to 'seeking'.
   Example flaky failure previously:
      FAIL Test seek starts on duration reduction below currentTime
      assert_equals: Event types match. expected "seeking" but got
      "timeupdate"

BUG=689781,641121

Change-Id: Ie2a0f2171afda4cf1196f3eff1944f118dd6b2be
Reviewed-on: https://chromium-review.googlesource.com/606746
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493447}
[modify] https://crrev.com/008f8daf59e8d74ea3bf5a27e7d5d3ae9132c4bd/third_party/WebKit/LayoutTests/http/tests/media/media-source/mediasource-duration.html

 Issue 854711  has been merged into this issue.

external/wpt/media-source/mediasource-append-buffer.html's 'Test appendBuffer events order.' fails due to to at least four things:

* loadedmetadata is expected to fire before updateend (though MSE spec doesn't appear to require using the same task queue as MediaElement) --> so perhaps a test problem
* HAVE_METADATA is expected to have been reached when handling updateend of the corresponding append that triggers it (which MSE spec is clear about, though perhaps too strict) --> so perhaps a spec or Chrome impl problem. Firefox has reported similarly; they delay such updateend until loadedmetadata fires.

Ditto for loadeddata and HAVE_CURRENT_DATA, except (like Chrome) reaching HAVE_CURRENT_DATA is done async after parsing as part of renderer prerolling/decoding, so Firefox doesn't do such updateend delay for loadeddata. --> so perhaps a spec issue since 2 implementors have issues transitioning first time to HAVE_CURRENT_DATA without unduly impairing parsing latency exposed to app via updatestart->updateend.