Remove what remains of MediaControllerInterface

Remove what remains of MediaControllerInterface

The currentTime() and duration() should simply use the media element, as
that is what paintMediaSlider() in RenderMediaControls uses, so the
existing code would not work if the media element and its controller had
different durations.

setCurrentTime() does require taking the controller into account, so add
some tests and expand that final instance of mediaControllerInterface().

BUG=341813, 341852
TEST=LayoutTests/media/controls-timeline.html
     LayoutTests/media/controls-timeline-with-controller.html

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=170512

[philipj_slow, 2014-03-31 17:30:11]

PTAL. https://codereview.chromium.org/219523004/ is needed for the new test to
pass, so no trybots up front.

[acolwell GONE FROM CHROMIUM, 2014-03-31 23:23:13]

lgtm % nit

https://codereview.chromium.org/219283004/diff/1/Source/core/html/shadow/Medi...
File Source/core/html/shadow/MediaControlElements.cpp (right):

https://codereview.chromium.org/219283004/diff/1/Source/core/html/shadow/Medi...
Source/core/html/shadow/MediaControlElements.cpp:378:
mediaElement().controller()->setCurrentTime(time, IGNORE_EXCEPTION);
nit: We should probably have a FIXME: here that indicates we'll need to properly
apply the media element's relative offset, once "timeline offset"(aka
getStartDate()) is implemented. A bug should probably be filed and associated
with http://crbug.com/312699

[philipj_slow, 2014-04-01 03:22:31]

https://codereview.chromium.org/219283004/diff/1/Source/core/html/shadow/Medi...
File Source/core/html/shadow/MediaControlElements.cpp (right):

https://codereview.chromium.org/219283004/diff/1/Source/core/html/shadow/Medi...
Source/core/html/shadow/MediaControlElements.cpp:378:
mediaElement().controller()->setCurrentTime(time, IGNORE_EXCEPTION);
On 2014/03/31 23:23:13, acolwell wrote:
> nit: We should probably have a FIXME: here that indicates we'll need to
properly
> apply the media element's relative offset, once "timeline offset"(aka
> getStartDate()) is implemented. A bug should probably be filed and associated
> with http://crbug.com/312699

getStartDate() returns the "timeline offset" which is "an explicit date and time
corresponding to the zero time in the media timeline" so I don't think that's
quite right.

The "earliest possible position" is however something that would affect the
media controls. https://code.google.com/p/chromium/issues/detail?id=137275 is
about that, so I've commented in that bug and will add a FIXME in the code
pointing to it.

[philipj_slow, 2014-04-01 03:25:59]

The CQ bit was checked by philipj@opera.com

[commit-bot: I haz the power, 2014-04-01 03:26:10]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/philipj@opera.com/219283004/20001

[commit-bot: I haz the power, 2014-04-01 04:38:42]

Change committed as 170512

[acolwell GONE FROM CHROMIUM, 2014-04-01 15:23:41]

On 2014/04/01 03:22:31, philipj wrote:
>
https://codereview.chromium.org/219283004/diff/1/Source/core/html/shadow/Medi...
> File Source/core/html/shadow/MediaControlElements.cpp (right):
> 
>
https://codereview.chromium.org/219283004/diff/1/Source/core/html/shadow/Medi...
> Source/core/html/shadow/MediaControlElements.cpp:378:
> mediaElement().controller()->setCurrentTime(time, IGNORE_EXCEPTION);
> On 2014/03/31 23:23:13, acolwell wrote:
> > nit: We should probably have a FIXME: here that indicates we'll need to
> properly
> > apply the media element's relative offset, once "timeline offset"(aka
> > getStartDate()) is implemented. A bug should probably be filed and
associated
> > with http://crbug.com/312699
> 
> getStartDate() returns the "timeline offset" which is "an explicit date and
time
> corresponding to the zero time in the media timeline" so I don't think that's
> quite right.

I was actually referring to the paragraph above the "media resource end
position" definition
(http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#media-reso...).
IIUC two media elements 0 time don't line up if their "timestamp offsets" are
different. The code would have to apply its relative offset to the time passed
to the controller if it doesn't happen to be the HTMLMediaElement with the
earliest "timestamp offset". This could get somewhat confusing in the UI since
depending on which HTMLMediaElement's controls you are using, you may not be
able to seek to the beginning of the presentation.

[philipj_slow, 2014-04-02 20:35:57]

On 2014/04/01 15:23:41, acolwell wrote:
> On 2014/04/01 03:22:31, philipj wrote:
> >
>
https://codereview.chromium.org/219283004/diff/1/Source/core/html/shadow/Medi...
> > File Source/core/html/shadow/MediaControlElements.cpp (right):
> > 
> >
>
https://codereview.chromium.org/219283004/diff/1/Source/core/html/shadow/Medi...
> > Source/core/html/shadow/MediaControlElements.cpp:378:
> > mediaElement().controller()->setCurrentTime(time, IGNORE_EXCEPTION);
> > On 2014/03/31 23:23:13, acolwell wrote:
> > > nit: We should probably have a FIXME: here that indicates we'll need to
> > properly
> > > apply the media element's relative offset, once "timeline offset"(aka
> > > getStartDate()) is implemented. A bug should probably be filed and
> associated
> > > with http://crbug.com/312699
> > 
> > getStartDate() returns the "timeline offset" which is "an explicit date and
> time
> > corresponding to the zero time in the media timeline" so I don't think
that's
> > quite right.
> 
> I was actually referring to the paragraph above the "media resource end
> position" definition
>
(http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#media-reso...).
> IIUC two media elements 0 time don't line up if their "timestamp offsets" are
> different. The code would have to apply its relative offset to the time passed
> to the controller if it doesn't happen to be the HTMLMediaElement with the
> earliest "timestamp offset". This could get somewhat confusing in the UI since
> depending on which HTMLMediaElement's controls you are using, you may not be
> able to seek to the beginning of the presentation.

Oh, I had completely overlooked that bit. Will add a FIXME.