Open Bug 477434 Opened 15 years ago Updated 2 years ago

videocontrols test encounters incorrect seeking behavior

Categories

(Toolkit :: Video/Audio Controls, defect)

x86
Windows XP
defect

Tracking

()

People

(Reporter: Dolske, Unassigned)

Details

I added some tests for bug 462113, and found that the XP tinderbox will occasionally fail. The test basically does:

1) Click play+pause a few times (exisiting tests). Final state is paused.
2) Test sets video.currentTime to 0, to ensure we're at a known position.
3) We get a seeking event
4) We get a seeked event.

After step 4, the test checks to see if .currentTime == 0. It usually is, but randomly fails because .currentTime is actually 0.0989999994635582.

The logged sequence of events from the test is:
...
----- test #9 -----
checking event type
checking video play state
checking video mute state
video position is at 0
----- test #10 -----
checking event type
video position is at 0
----- test #11 -----
checking event type
checking playback position - got 0.0989999994635582, expected 0
----- test #12 -----
...

http://hg.mozilla.org/mozilla-central/annotate/dc047fe66164/toolkit/content/tests/widgets/test_videocontrols.html

Test #9 is logging the time position before it changes it. It's not unexpected to have .currentTime already == 0 here (the test happened to click play/pause really fast). It's still 0 in test 10 (the seeking event), but test 11 (the seeked event) got 0.98999.

How the heck did setting .currentTime to 0 make it go forward?! Two green cycles also had .currentTime == 0 in test #9, so that alone isn't enough to trigger this.
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.