Media Controls: Fix seek to end when max attr is rounded up

third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp

Index: third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp
diff --git a/third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp b/third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp
index 567a7a7586c5d42f09d9217ab8a3fbba13960162..eac75ab2c736f1d7cb4132ffec13f6190a2adcc9 100644
--- a/third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp
+++ b/third_party/WebKit/Source/core/html/shadow/MediaControlElements.cpp
@@ -770,6 +770,14 @@ void MediaControlTimelineElement::defaultEventHandler(Event* event) {
 
   double time = value().toDouble();
 
+  double duration = mediaElement().duration();
+  double maxAttribute = getFloatingPointAttribute(maxAttr);
+  // Workaround for floating point error - it's possible for this element's max
+  // attribute to be rounded to a value slightly higher than the duration. If
+  // this happens and scrubber is dragged near the max, seek to duration.
+  if (duration < time && time <= maxAttribute && maxAttribute <= duration + 0.5)
+    time = duration;

[mlamouri (slow - plz ping), 2017/02/27 17:48:12]

I do not understand why this isn't:
```
if (duration < time)
  time = duration;
```
or said otherwise: `time = std:min(time, duration);`

I bet there is a reason. I can actually guess why we do `time <= maxAttribute`
even though that sounds like we could drop the check. However, I don't
understand why `+0.5`.

[johnme, 2017/02/28 18:02:55]

Done.

I was guarding against the case where mediaElement().duration() and and
getFloatingPointAttribute(maxAttr) are significantly out of sync (not just by
rounding error), and trying not to change behaviour in that case. It seems that
can only happen if the webpage calls event.stopImmediatePropagation() in a
capturing durationchange event listener, and since that's such an edge case,
setting time to duration in that case is probably fine too (in fact, it probably
makes more sense).

(The 0.5 was to allow the seconds value to have been rounded, which increases it
by at most 0.5 seconds; though FWIW it seems that it's the milliseconds that get
rounded)

+
   // FIXME: This will need to take the timeline offset into consideration
   // once that concept is supported, see https://crbug.com/312699
   if (mediaElement().seekable()->contain(time))