Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically adding ccs based on suspected regression changelists:

Chrome style plugin: apply fixits in //third_party/blink/renderer/modules by dcheng@chromium.org - https://chromium.googlesource.com/chromium/src/+/ebc10f07e1fc46e03f7fc676fd562bedc4d1c18c

[EventTiming] Implement Event Timing API by maxlg@chromium.org - https://chromium.googlesource.com/chromium/src/+/6bc702ce4e6080adf5fff8e998e5138de88f1f7c

[Media Controls] Only act as audio element when controls are enabled by steimel@chromium.org - https://chromium.googlesource.com/chromium/src/+/00c3cffbbeff11db315ac4d74bb274558a9f26d6

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.

I checked out 3f1e986f9c213d8d8833a8a006771568808c5227 (the commit before my "[Media Controls] Only act as audio element when controls are enabled" change) and it was still broken.

Also of note is that the MediaControlTimeDisplayElement code that seems to be failing hasn't been touched in a while, so either this has been an issue for much longer than the range suggests, or something that used to sanitize the duration further up the line no longer does so

maxlg@, dcheng@ : Could you please look into this issue...

I've just taken a look. The issue is about failing to cast a time from double to integer for MediaControlTimeDisplayElement.

But my CL doesn't deal with MediaControlTimeDisplayElement. My CL just adds on new features without affecting the existing logics. So it's not likely to be the cause from this point of view.

What does the duration in MediaControlTimeDisplayElement mean? Why is this value so large? What's the normal range of this value? Is it possible that the duration is more likely to become bigger when the absolute wall clock time moves forward? 

Predator and CL could not provide any possible suspects.

Using Code Search for the file, "media_control_slider_element.cc" suspecting the below Cl might have caused this issue

Suspect CL: https://chromium.googlesource.com/chromium/src/+/5f02ed9270f274ed7dd1cc6a861bcd6eb2d65892

beccahughes@ -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

That CL is not the cause but I have an idea what is so I can fix this.

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

commit b838150fcff025c61d9b6ed54d0f241c1ff24101
Author: Becca Hughes <beccahughes@chromium.org>
Date: Wed Jul 11 16:41:58 2018

[Media Controls] Fix integer cast

MediaControlSliderElement is causing a ClusterFuzz error
because we are casting a float to an int that could
overflow.

BUG= 852364 

Change-Id: Ic454a79ebf6ef8d40f85e054a70cb87030c6db9c
Reviewed-on: https://chromium-review.googlesource.com/1131921
Commit-Queue: Becca Hughes <beccahughes@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574191}
[modify] https://crrev.com/b838150fcff025c61d9b6ed54d0f241c1ff24101/third_party/blink/renderer/modules/media_controls/elements/media_control_slider_element.cc

ClusterFuzz testcase 5560200610971648 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.