If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Video controls cause 'pause' and 'play' events to fire when seeking

NEW
Unassigned

Status

()

Core
Audio/Video: Playback
--
major
6 years ago
2 years ago

People

(Reporter: Matt Combs, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0

When seeking a video element (have yet to test with audio), Events fire in this order: Pause, Seeking, Seeked, Play. According to the working draft the only events that should fire are Seeking, then seeked once the user has stopped seeking.

Reproducible: Always

Steps to Reproduce:
1.Load HTML5 video element
2.Seek video

Actual Results:  
Fired events Pause,Seeking,Seeked,Play

Expected Results:  
Should have fired Seeking,Seeked

http://dev.w3.org/html5/spec/Overview.html#seeking

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12970#c1
How are you detecting fired events? Can you provide a minimized test case?
(Reporter)

Comment 2

6 years ago
I can provide one later I'll have to create new videos more optimized for the web (size wise). I've bound event handlers to the video element using addEventListener() to listen for the following events "play", "pause", "seeked", and "seeking". Then I'm using console.log to return the values to the console with the videos currentTime.

Here is a minitest (it will be live after 5:15pm EST @ next deployment)

http://www.reyrey.com/tests/videos/demo.html
(Reporter)

Comment 3

6 years ago
Also looks like as of 5.0 the firing order is a little different. I seem to get now Pause, Seeking, Play, Seeked
Thanks for the test video...would it be possible for you modify your test page to report the events as text below the video?
You must be seeking using the built in video controls. What you're seeing is the video controls pausing the video while it seeks, and playing afterwards. If you perform a seek using |video.currentTime = t|, you won't see the "pause" and "play" events fire.

Firefox's seek implementation is spec compliant WRT the events fired, it's just that the controls are calling pause() and play() which are firing events as required by the spec.
(In reply to comment #2)
> Here is a minitest (it will be live after 5:15pm EST @ next deployment)
> 
> http://www.reyrey.com/tests/videos/demo.html

Note this video is rendered at the incorrect aspect ratio, this bug 661456.
(In reply to comment #5)
> Firefox's seek implementation is spec compliant WRT the events fired, it's
> just that the controls are calling pause() and play() which are firing
> events as required by the spec.

Chris, it sounds like you think this bug is either INVALID or WONTFIX. Am I accurate in this assumption? Please advise.
(Reporter)

Comment 8

6 years ago
I understand I had just saw that recommendation request at W3 where it said to report such activity to the browser maker. So is it now recommend for cross browser event tracking to roll your own controls to keep things consistent?
(Reporter)

Comment 9

6 years ago
Test page updated per Anthony's request.
(In reply to comment #7)
> Chris, it sounds like you think this bug is either INVALID or WONTFIX. Am I
> accurate in this assumption? Please advise.

I am unsure whether we should change behaviour here or not.

(In reply to comment #8)
> I understand I had just saw that recommendation request at W3 where it said
> to report such activity to the browser maker.

Thank you for reporting the bug. It's always useful reporting bugs. Even if we were to resolve the bug WONTFIX or as a duplicate, it still gives us a feel for how often people run into a particular problem.

> So is it now recommend for
> cross browser event tracking to roll your own controls to keep things
> consistent?

It sounds like you're already rolling your own controls for some other reason, otherwise you wouldn't have noticed this.

Inconsistency between when browsers fire events is not desirable however.
(Reporter)

Comment 11

6 years ago
I discovered the bug while trying to create a tool for users to get detailed usage information from their HTML5 videos regardless if they are using custom controls, or built in controls (trying to keep it small but track usage based solely on video events).

Thanks for looking into this!
Yeah, we should probably fix this so we're consistent with other implementations, and to avoid surprises for web devs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Video element incorrect event firing → Video controls cause 'pause' and 'play' events to fire when seeking
Just to expand a bit on why the default controls do this... When dragging the scrubber, we get events (internally) for the value changes of the scrubber widget, and start seeking to those positions. But if the video stays in the play-state, it makes for a rather disorienting position as it plays (with sound!) small chunks of the media as you seek around. Indeed, if you drag and linger at a spot, the video would play onward from that spot until you jiggle the mouse by a pixel and it jumps to the new spot.

It's a fair point about the events seeming unexpected.

_If_ we wanted to avoid that I suppose we could introduce mozPlayNoEvent() / mozPauseNoEvent() to temporarily suspend playback while the user seeks. But I'd suspect that would be tricky to get right, you'd have to fudge the video's other states, and this stuff isn't exactly simple. :( Also, someone else might break if they were expecting playback to continue during the seek (ie, because it never seemed to pause).

Maybe this should just be explicitly addressed in the spec somehow?
Component: Audio/Video → Audio/Video: Playback
You need to log in before you can comment on or make changes to this bug.