http/tests/media/video-play-progress.html times out on repeated runs |
||
Issue descriptionbuild target: blink_tests command: python third_party/WebKit/Tools/Scripts/run-webkit-tests -t Default --no-retry-failures http/tests/media/video-play-progress.html --iterations=2 This test simply wants the "progress" event to fire. For me the second run always fails, firing a "suspend" event without at least one "progress". HTMLMediaElement makes an attempt to always fire at least one "progress" event in HTMLMediaElement::changeNetworkStateFromLoadingToIdle, but the firing is conditioned on webMediaPlayer()->didLoadingProgress(). I think caching in the second run causes didLoadingProgress to evaluate false. Passing and failing logs attached
,
Oct 31 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664 commit 0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664 Author: hubbe <hubbe@chromium.org> Date: Mon Oct 31 19:50:05 2016 Make sure we get at least one progress callback When media is already cached, we don't get any progress callbacks, which confuse clients. Make sure we get at least one progress callback. This CL is an update of cr/2437273002, which solves a similiar problem. BUG= 657922 , 658950 Review-Url: https://codereview.chromium.org/2445993003 Cr-Commit-Position: refs/heads/master@{#428773} [modify] https://crrev.com/0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664/media/blink/multibuffer_data_source.cc [modify] https://crrev.com/0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664/media/blink/multibuffer_data_source.h [modify] https://crrev.com/0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664/media/blink/multibuffer_data_source_unittest.cc
,
Oct 31 2016
|
||
►
Sign in to add a comment |
||
Comment 1 by hubbe@chromium.org
, Oct 26 2016