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

commit beffb95cc370cf3420cdfb2776f3173cc2a30c8b
Author: Guido Urdaneta <guidou@chromium.org>
Date: Wed Feb 07 15:45:51 2018

Mark external/wpt/media-source/mediasource-duration.html as flaky

This test is crashing flakily on Linux bots

Bug:  809998 
Change-Id: I795bf80686353c6916fa4637dbd3f124fcb0d246
TBR: wolenetz@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/906729
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535007}
[modify] https://crrev.com/beffb95cc370cf3420cdfb2776f3173cc2a30c8b/third_party/WebKit/LayoutTests/TestExpectations

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

commit eb2c637c78cb4553e1a3242b89d4e6114c7a299f
Author: Guido Urdaneta <guidou@chromium.org>
Date: Wed Feb 07 16:27:22 2018

Fix expectation for flaky test.

Bug:  809998 
Change-Id: I2cd1ca2b81a066fcb344a8a2861e9bd5e0ca2a1c
TBR: wolenetz@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/906929
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535022}
[modify] https://crrev.com/eb2c637c78cb4553e1a3242b89d4e6114c7a299f/third_party/WebKit/LayoutTests/TestExpectations

+Dale

The flakiness dashboard (https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=webkit_layout_tests&tests=mediasource-duration) shows a return to non-crashiness after a period of crashing that highly correlates with the revision range for the land and revert of Dale's patch (revert was https://chromium.googlesource.com/chromium/src/+/0affd0504bdad5b2a5c4777f46f200a6a43eb9ed).

Dale, please watch external/wpt/media-source/mediasource-duration.html on reland attempts of your fix(es) for  bug 694855  and  bug 756897 .

Meanwhile, I'll land a revert of the net of #1 and #4, to remove the crash expectation that was added yesterday before the root cause was itself reverted.

CL: https://chromium-review.googlesource.com/c/chromium/src/+/907428

What is the actual crash here? Why isn't the layout test dump symbolized? :/

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

commit 48836201498b4e560c1687dc5b33bd7c0880f588
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Wed Feb 07 21:13:58 2018

Remove crash expectation from external mediasource-duration layout test

Removes crash expectation now that the root cause CL itself was
reverted.  See
https://bugs.chromium.org/p/chromium/issues/detail?id=809998#c5.

BUG= 809998 

Change-Id: Ia7ad92ce41c34aba974f5a37f64c7a26f88ffb4d
Reviewed-on: https://chromium-review.googlesource.com/907428
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535144}
[modify] https://crrev.com/48836201498b4e560c1687dc5b33bd7c0880f588/third_party/WebKit/LayoutTests/TestExpectations

@#8: Likewise, I don't see any crash details in those logs. Nor could I repro it locally on linux with your patch not yet reverted (though my build included proprietary codecs and is on a Z620, both might impact timing significantly versus the bot). Infra folks might be able to help figure out why breakpad/crash stack didn't get reported. I'm less clear about why your change might be crashing flakily other than there's media removal, duration reduction, and seeking operations all while the element is playing. The interaction between PotentiallyPlaying and seeking is a lot less clear to me, but maybe there's something in there causing the crash.

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

commit b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Tue Feb 13 21:39:28 2018

Remove kHaveFutureData restriction from play state notifications.

This reland marks media-src-suspend-after-have-future-data and
media-src-suspend-after-have-metadata as SlowTest(s) now that they no
longer permanently time out. Each takes ~2ish seconds in release build
and so meets the criteria for being a SlowTest.

This also changes WMPI to not try and get the current time value prior
to the HaveCurrentData state (which Blink already respects).

========= [ Original Description Follows ] ===============

HTMLMediaElement should tell WebMediaPlayer about play state changes
as soon as the kHaveMetaData state is reached.

This will eventually allow us to delete a bunch of guessing-game type
code for idle suspension and instead rely on actually getting a play()
call from Blink to wake up when needed.

We can't stop WMPI from reaching the future data state quite yet though,
because it has implications on the delivery of 'canplay' and 'canplaythrough'
events that need to be part of a larger preload=metadata experiment. See old
discussion on this here:

https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jul/0007.html

Note: This change exposed some bugs in how the ready state maximum is used
and the states at which a video frame is expected. These issues are fixed
in the HTMLVideoElement.

BUG= 694855 ,  756897 ,  809998 
TEST=existing suspend tests no longer flake.

Change-Id: Ie6297df474c1f5da56ca6c0e81efa636fbc349bf
Reviewed-on: https://chromium-review.googlesource.com/915081
Reviewed-by: Frank Liberato <liberato@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536487}
[modify] https://crrev.com/b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4/third_party/WebKit/LayoutTests/SlowTests
[modify] https://crrev.com/b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4/third_party/WebKit/Source/core/html/media/HTMLMediaElement.cpp
[modify] https://crrev.com/b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4/third_party/WebKit/Source/core/html/media/HTMLVideoElement.cpp

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

commit dc5d47c8ab0d958bdd967a834c472106f9697375
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Thu Feb 15 11:15:19 2018

Revert "Remove kHaveFutureData restriction from play state notifications."

This reverts commit b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4.

Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=812423

Original change's description:
> Remove kHaveFutureData restriction from play state notifications.
> 
> This reland marks media-src-suspend-after-have-future-data and
> media-src-suspend-after-have-metadata as SlowTest(s) now that they no
> longer permanently time out. Each takes ~2ish seconds in release build
> and so meets the criteria for being a SlowTest.
> 
> This also changes WMPI to not try and get the current time value prior
> to the HaveCurrentData state (which Blink already respects).
> 
> ========= [ Original Description Follows ] ===============
> 
> HTMLMediaElement should tell WebMediaPlayer about play state changes
> as soon as the kHaveMetaData state is reached.
> 
> This will eventually allow us to delete a bunch of guessing-game type
> code for idle suspension and instead rely on actually getting a play()
> call from Blink to wake up when needed.
> 
> We can't stop WMPI from reaching the future data state quite yet though,
> because it has implications on the delivery of 'canplay' and 'canplaythrough'
> events that need to be part of a larger preload=metadata experiment. See old
> discussion on this here:
> 
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jul/0007.html
> 
> Note: This change exposed some bugs in how the ready state maximum is used
> and the states at which a video frame is expected. These issues are fixed
> in the HTMLVideoElement.
> 
> BUG= 694855 ,  756897 ,  809998 
> TEST=existing suspend tests no longer flake.
> 
> Change-Id: Ie6297df474c1f5da56ca6c0e81efa636fbc349bf
> Reviewed-on: https://chromium-review.googlesource.com/915081
> Reviewed-by: Frank Liberato <liberato@chromium.org>
> Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
> Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#536487}

TBR=dalecurtis@chromium.org,mlamouri@chromium.org,liberato@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  694855 ,  756897 ,  809998 
Change-Id: I176b5116682851853ff2773e6e4a77a9ac2664b2
Reviewed-on: https://chromium-review.googlesource.com/920481
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536988}
[modify] https://crrev.com/dc5d47c8ab0d958bdd967a834c472106f9697375/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/dc5d47c8ab0d958bdd967a834c472106f9697375/third_party/WebKit/LayoutTests/SlowTests
[modify] https://crrev.com/dc5d47c8ab0d958bdd967a834c472106f9697375/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/dc5d47c8ab0d958bdd967a834c472106f9697375/third_party/WebKit/Source/core/html/media/HTMLMediaElement.cpp
[modify] https://crrev.com/dc5d47c8ab0d958bdd967a834c472106f9697375/third_party/WebKit/Source/core/html/media/HTMLVideoElement.cpp

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

commit d1d5207d97b36a4f46a62563860b5792735db554
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Thu Feb 15 17:37:20 2018

Revert "Remove kHaveFutureData restriction from play state notifications."

This reverts commit b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4.

Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=812423

Original change's description:
> Remove kHaveFutureData restriction from play state notifications.
> 
> This reland marks media-src-suspend-after-have-future-data and
> media-src-suspend-after-have-metadata as SlowTest(s) now that they no
> longer permanently time out. Each takes ~2ish seconds in release build
> and so meets the criteria for being a SlowTest.
> 
> This also changes WMPI to not try and get the current time value prior
> to the HaveCurrentData state (which Blink already respects).
> 
> ========= [ Original Description Follows ] ===============
> 
> HTMLMediaElement should tell WebMediaPlayer about play state changes
> as soon as the kHaveMetaData state is reached.
> 
> This will eventually allow us to delete a bunch of guessing-game type
> code for idle suspension and instead rely on actually getting a play()
> call from Blink to wake up when needed.
> 
> We can't stop WMPI from reaching the future data state quite yet though,
> because it has implications on the delivery of 'canplay' and 'canplaythrough'
> events that need to be part of a larger preload=metadata experiment. See old
> discussion on this here:
> 
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jul/0007.html
> 
> Note: This change exposed some bugs in how the ready state maximum is used
> and the states at which a video frame is expected. These issues are fixed
> in the HTMLVideoElement.
> 
> BUG= 694855 ,  756897 ,  809998 
> TEST=existing suspend tests no longer flake.
> 
> Change-Id: Ie6297df474c1f5da56ca6c0e81efa636fbc349bf
> Reviewed-on: https://chromium-review.googlesource.com/915081
> Reviewed-by: Frank Liberato <liberato@chromium.org>
> Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
> Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#536487}

TBR=dalecurtis@chromium.org,mlamouri@chromium.org,liberato@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  694855 ,  756897 ,  809998 
Change-Id: I176b5116682851853ff2773e6e4a77a9ac2664b2
Reviewed-on: https://chromium-review.googlesource.com/920481
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#536988}(cherry picked from commit dc5d47c8ab0d958bdd967a834c472106f9697375)
Reviewed-on: https://chromium-review.googlesource.com/922301
Reviewed-by: Claude Masso <cmasso@chromium.org>
Cr-Commit-Position: refs/branch-heads/3348@{#3}
Cr-Branched-From: 62c55a88a1aa6b877054b25d06e3ab0ea505d253-refs/heads/master@{#536934}
[modify] https://crrev.com/d1d5207d97b36a4f46a62563860b5792735db554/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/d1d5207d97b36a4f46a62563860b5792735db554/third_party/WebKit/LayoutTests/SlowTests
[modify] https://crrev.com/d1d5207d97b36a4f46a62563860b5792735db554/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/d1d5207d97b36a4f46a62563860b5792735db554/third_party/WebKit/Source/core/html/media/HTMLMediaElement.cpp
[modify] https://crrev.com/d1d5207d97b36a4f46a62563860b5792735db554/third_party/WebKit/Source/core/html/media/HTMLVideoElement.cpp

Fixed since was reverted. We can reevaluate if we attempt to remove this lie again.