Add back HTMLMediaElement::m_lastTimeUpdateEventMovieTime.

Add back HTMLMediaElement::m_lastTimeUpdateEventMovieTime.

I was too aggressive removing this code as it actually is nice to not
fire duplicate timeupdate events when currentTime hasn't changed.

The real fix is to leave it in, but to ignore it when firing
non-periodic timeupdate events.

For whatever it's worth, this also matches what Firefox does.

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

[scherkus (not reviewing), 2014-09-17 23:57:25]

scherkus@chromium.org changed reviewers:
+ philipj@opera.com

[scherkus (not reviewing), 2014-09-17 23:59:22]

PS#1 is revert
PS#2 is my changes to the revert

I tried stuffing everything into a big if statement but felt it was a bit
unwieldy -- let me know what you think.

[philipj_slow, 2014-09-18 15:11:32]

LGTM.

If possible, could you add a test that fails with the old code but passes now?

[philipj_slow, 2014-09-18 18:52:33]

This seems pretty likely to be causing a new GC test to fail
<https://codereview.chromium.org/552303006/#msg66>, so I'm going to CQ this and
we can talk about the test as a follow-up.

[philipj_slow, 2014-09-18 18:52:51]

The CQ bit was checked by philipj@opera.com

[philipj_slow, 2014-09-18 18:52:52]

lgtm

[commit-bot: I haz the power, 2014-09-18 18:53:44]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/578113002/20001

[commit-bot: I haz the power, 2014-09-18 18:59:35]

Committed patchset #2 (id:20001) as 182260

[scherkus (not reviewing), 2014-09-18 20:51:03]

On 2014/09/18 15:11:32, philipj wrote:
> LGTM.
> 
> If possible, could you add a test that fails with the old code but passes now?

It's a bit tricky to write a test for this as it was non-deterministic behaviour
(the media engine would have to be struggling to advance to the clock). Luckily
the Mac bots were able to trigger it as we had already-failing tests.

I've since updated TestExpectations now that they're passing reliably:
https://src.chromium.org/viewvc/blink?view=rev&revision=182267

[scherkus (not reviewing), 2014-09-18 20:51:13]

On 2014/09/18 18:52:33, philipj wrote:
> This seems pretty likely to be causing a new GC test to fail
> <https://codereview.chromium.org/552303006/#msg66>, so I'm going to CQ this
and
> we can talk about the test as a follow-up.

I'll take a look at that.

[philipj_slow, 2014-09-18 21:09:53]

On 2014/09/18 20:51:03, scherkus wrote:
> On 2014/09/18 15:11:32, philipj wrote:
> > LGTM.
> > 
> > If possible, could you add a test that fails with the old code but passes
now?
> 
> It's a bit tricky to write a test for this as it was non-deterministic
behaviour
> (the media engine would have to be struggling to advance to the clock).
Luckily
> the Mac bots were able to trigger it as we had already-failing tests.
> 
> I've since updated TestExpectations now that they're passing reliably:
> https://src.chromium.org/viewvc/blink?view=rev&revision=182267

OK, I wasn't sure if maybe there was a way to provoke it deterministically by
seeking to 0 repeatedly or... something. If it's inherently racy, then flaky
tests becoming non-flaky is all the proof required.