Closed mfn closed 10 years ago
After some more testing I think that in play
it was meant to reset seeking
to false
. Some testing showed good result.
However, there's one case which is still a problem after this change:
Successive pause/play events however are triggered.
Hey @mfn,
You were right about the seeking = true
bug.
I fixed it in a previous commit.
I also fixed the issue with the play event not being sent after a seek.
I'm not sure what's here exactly at fault, but the play/pause events in my case are not tracked because "seeking" is "true" all the time.
The workflow I see is the following:
play
gets triggered for the first timecurrentTime === 0
which means theplay
beacon gets not sent; but that's ok (I guess), thestart
event was triggered before anyway. But nevertheless,seeking
gets set totrue
pause
, the check looks like this:if currentTime != duration && !seeking
. Since nowseeking
has been set totrue
and I don't see code setting it to false, play/pause will never trigger sendbeaconI removed the
seeking = true
inplay
and in my limited testing it worked.