222183 2021-02-19 10:48:15 -0800 [BigSur+ Wk2] imported/w3c/web-platform-tests/media-source/mediasource-seek-during-pending-seek.html is a flakey failure 2021-07-22 16:47:13 -0700 1 1 1 Unclassified WebKit New Bugs WebKit Nightly Build Unspecified Unspecified RESOLVED WORKSFORME InRadar P2 Normal --- 1 amir_mark webkit-unassigned jean-yves.avenard jenner tsavell webkit-bot-watchers-bugzilla webkit-bug-importer oldest_to_newest 1731425 0 amir_mark 2021-02-19 10:48:15 -0800 imported/w3c/web-platform-tests/media-source/mediasource-seek-during-pending-seek.html Is a flakey failure on BigSur Wk2 History: https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fmedia-source%2Fmediasource-seek-during-pending-seek.html Text Diff: --- /Volumes/Data/slave/bigsur-release-tests-wk2/build/layout-test-results/imported/w3c/web-platform-tests/media-source/mediasource-seek-during-pending-seek-expected.txt +++ /Volumes/Data/slave/bigsur-release-tests-wk2/build/layout-test-results/imported/w3c/web-platform-tests/media-source/mediasource-seek-during-pending-seek-actual.txt @@ -1,4 +1,6 @@ + +Harness Error (TIMEOUT), message = null PASS Test seeking to a new location before transitioning beyond HAVE_METADATA. -PASS Test seeking to a new location during a pending seek. +TIMEOUT Test seeking to a new location during a pending seek. Test timed out 1731426 1 webkit-bug-importer 2021-02-19 10:48:45 -0800 <rdar://problem/74528766> 1732681 2 421348 amir_mark 2021-02-23 13:54:21 -0800 Created attachment 421348 Patch 1732692 3 421348 tsavell 2021-02-23 14:38:29 -0800 Comment on attachment 421348 Patch Clearing flags on attachment: 421348 Committed r273335 (234487@main): <https://commits.webkit.org/234487@main> 1759554 4 jean-yves.avenard 2021-05-12 22:24:56 -0700 I haven't been able to reproduce the TIMEOUT error. However, I can easily reproduce the error: ` FAIL Test seeking to a new location before transitioning beyond HAVE_METADATA. assert_equals: Event types match. expected "seeked" but got "playing" ` Upon review of the spec and how this test is written, the behaviour seen is correct. This test can intermittently fail and this is to be expected. https://github.com/web-platform-tests/wpt/blob/89505713ad43568e8e9c985d489a59209aaebad6/media-source/mediasource-seek-during-pending-seek.html#L50 The test does the following. mediaElement.play() mediaElement.currentTime = non_buffered_area; it will then append data at currenTime and make sure that the `seeked` event is fired before `playing` The `playing` event is to be fired according to HTML5 spec when the internal play steps are running. https://html.spec.whatwg.org/multipage/media.html#internal-play-steps > 3. If the media element's paused attribute is true, then: > 1. Change the value of paused to false. > 2. If the show poster flag is true, set the element's show poster flag to false and run the time marches on steps. > 3. Queue a media element task given the media element to fire an event named play at the element. > 4. If the media element's readyState attribute has the value HAVE_NOTHING, HAVE_METADATA, or HAVE_CURRENT_DATA, queue a media element task given the media element to fire an event named waiting at the element. > Otherwise, the media element's readyState attribute has the value HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA: notify about playing for the element. > The other non-normative reference to when the `playing` event is to be fired is when: https://html.spec.whatwg.org/multipage/media.html#event-media-playing > readyState is newly equal to or greater than HAVE_FUTURE_DATA and paused is false, or paused is newly false and readyState is equal to or greater than HAVE_FUTURE_DATA. Even if this event fires, the element might still not be potentially playing, e.g. if the element is paused for user interaction or paused for in-band content. mediaElement.play() was called early in the test, so mediaElement.paused attribute is false. So the next time the mediaElement should be firing the `playing` event is when readyState moves to a value equal or greater than HAVE_FUTURE_DATA. Media Source Extension clarifies the following when it comes to seeking: https://w3c.github.io/media-source/#mediasource-seeking > 1. If new playback position is not in any TimeRanges of HTMLMediaElement.buffered > If the HTMLMediaElement.readyState attribute is greater than HAVE_METADATA, then set the HTMLMediaElement.readyState attribute to HAVE_METADATA. > Note > > Per HTMLMediaElement ready states [HTML] logic, HTMLMediaElement.readyState changes may trigger events on the HTMLMediaElement. > The media element waits until an appendBuffer() call causes the coded frame processing algorithm to set the HTMLMediaElement.readyState attribute to a value greater than HAVE_METADATA. > So per spec, when seeking to a non-buffered area, readyState will be set to HAVE_METADATA (which the test properly checks) This is done while https://html.spec.whatwg.org/multipage/media.html#seeking : > Wait until the user agent has established whether or not the media data for the new playback position is available, and, if it is, until it has decoded enough data to play back that position. The HTML spec clearly specifies here that we are to wait for *decoded* data, not until data is available (e.g. buffered). Now the appendBuffer operation runs and the coded frame processing algorithm is run: https://w3c.github.io/media-source/#dfn-coded-frame-processing > 2. If the HTMLMediaElement.readyState attribute is HAVE_METADATA and the new coded frames cause HTMLMediaElement.buffered to have a TimeRanges for the current playback position, then set the HTMLMediaElement.readyState attribute to HAVE_CURRENT_DATA. > Note > > Per HTMLMediaElement ready states [HTML] logic, HTMLMediaElement.readyState changes may trigger events on the HTMLMediaElement. > > 3. If the HTMLMediaElement.readyState attribute is HAVE_CURRENT_DATA and the new coded frames cause HTMLMediaElement.buffered to have a TimeRanges that includes the current playback position and some time beyond the current playback position, then set the HTMLMediaElement.readyState attribute to HAVE_FUTURE_DATA. > So readyState during the appendBuffer and before `updateend` is fired should transition mediaElement.currentState from HAVE_METADATA to HAVE_FUTURE_DATA and fire the `playing` event. So the order of operation when seeking in this test becomes: 1- wait until we have buffered data 2a- modify readyState to HAVE_FUTURE_DATA 2b- wait until we have enough decoded data 3- complete seeking. When we complete the seeking operation, the `seeked` event will be fired. Step 2a and 2b can be done in parallel, it is possible that we have enough decoded data at the same time the readyState is being modified. so we can't assert that the `seeked` event will be fired before the `playing` event. The opposite should be a more regular occurrence. I have opened a WPT bug: https://github.com/web-platform-tests/wpt/issues/28984 1778897 5 jenner 2021-07-22 16:47:13 -0700 Expanding expectations to included BigSur+: https://trac.webkit.org/changeset/280208/webkit 421348 2021-02-23 13:54:21 -0800 2021-02-23 14:38:29 -0800 Patch bug-222183-20210223155420.patch text/plain 1567 amir_mark U3VidmVyc2lvbiBSZXZpc2lvbjogMjczMzMxCmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9DaGFu Z2VMb2cgYi9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKaW5kZXggNzgxM2E3MjY5NDAxZWRjNDNmNTZk NGViYjFmZTAwMjA1OGNjMTljZi4uYzFjNWI3M2ZiNGRkZjk5ZDc0MDAyZTFjN2YyYmIwNWI3OWE4 MWY1MSAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCisrKyBiL0xheW91dFRlc3Rz L0NoYW5nZUxvZwpAQCAtMSwzICsxLDEyIEBACisyMDIxLTAyLTIzICBBbWlyIE1hcmsgSnIgIDxh bWlyX21hcmtAYXBwbGUuY29tPgorCisgICAgICAgIFtCaWdTdXIgV2syXSBpbXBvcnRlZC93M2Mv d2ViLXBsYXRmb3JtLXRlc3RzL21lZGlhLXNvdXJjZS9tZWRpYXNvdXJjZS1zZWVrLWR1cmluZy1w ZW5kaW5nLXNlZWsuaHRtbCBpcyBhIGZsYWtleSBmYWlsdXJlLgorICAgICAgICBodHRwczovL2J1 Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjIyMTgzCisKKyAgICAgICAgVW5yZXZpZXdl ZCB0ZXN0IGdhcmRlbmluZy4KKworICAgICAgICAqIHBsYXRmb3JtL21hYy13azIvVGVzdEV4cGVj dGF0aW9uczoKKwogMjAyMS0wMi0yMyAgRnJlZGVyaWMgV2FuZyAgPGZ3YW5nQGlnYWxpYS5jb20+ CiAKICAgICAgICAgTnVsbHB0ciBjcmFzaCBpbiBSZXBsYWNlU2VsZWN0aW9uQ29tbWFuZDo6cmVt b3ZlUmVkdW5kYW50U3R5bGVzQW5kS2VlcFN0eWxlU3BhbklubGluZQpkaWZmIC0tZ2l0IGEvTGF5 b3V0VGVzdHMvcGxhdGZvcm0vbWFjLXdrMi9UZXN0RXhwZWN0YXRpb25zIGIvTGF5b3V0VGVzdHMv cGxhdGZvcm0vbWFjLXdrMi9UZXN0RXhwZWN0YXRpb25zCmluZGV4IDkwYTg5NzcxNDAzYWI2OWU2 M2ZjYWNjYTBhNTViZTY3ZDAyN2U0YmIuLmVhMGY3NWQyNTNiN2YzMDEwYzlmNjU1NWM5ZDk1OGZj ZjhlODc5ZTQgMTAwNjQ0Ci0tLSBhL0xheW91dFRlc3RzL3BsYXRmb3JtL21hYy13azIvVGVzdEV4 cGVjdGF0aW9ucworKysgYi9MYXlvdXRUZXN0cy9wbGF0Zm9ybS9tYWMtd2syL1Rlc3RFeHBlY3Rh dGlvbnMKQEAgLTEzNzksNCArMTM3OSw2IEBAIHdlYmtpdC5vcmcvYi8yMjIxNDAgaW5zcGVjdG9y L2luZGV4ZWRkYi9jbGVhck9iamVjdFN0b3JlLmh0bWwgWyBQYXNzIFRpbWVvdXQgXQogCiB3ZWJr aXQub3JnL2IvMjIxOTMwIG1lZGlhL21lZGlhLWZyYWdtZW50cy9UQzAwMzQuaHRtbCBbIFNraXAg XQogCi13ZWJraXQub3JnL2IvMjIyMjA5IGluc3BlY3Rvci9kZWJ1Z2dlci9hc3luYy1zdGFjay10 cmFjZS1iYXNpYy5odG1sIFsgUGFzcyBUaW1lb3V0IF0KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBm aWxlCit3ZWJraXQub3JnL2IvMjIyMjA5IGluc3BlY3Rvci9kZWJ1Z2dlci9hc3luYy1zdGFjay10 cmFjZS1iYXNpYy5odG1sIFsgUGFzcyBUaW1lb3V0IF0KKword2Via2l0Lm9yZy9iLzIyMjE4MyBb IEJpZ1N1ciBdIGltcG9ydGVkL3czYy93ZWItcGxhdGZvcm0tdGVzdHMvbWVkaWEtc291cmNlL21l ZGlhc291cmNlLXNlZWstZHVyaW5nLXBlbmRpbmctc2Vlay5odG1sIFsgUGFzcyBGYWlsdXJlIF0K XCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCg==