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

Status: RESOLVED INACTIVE

(Core :: Audio/Video: Playback, defect)

Description

[Matt Combs]

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

Comment 1

[u279076]

How are you detecting fired events? Can you provide a minimized test case?

Comment 2

[Matt Combs]

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

Comment 3

[Matt Combs]

Also looks like as of 5.0 the firing order is a little different. I seem to get now Pause, Seeking, Play, Seeked

Comment 4

[u279076]

Thanks for the test video...would it be possible for you modify your test page to report the events as text below the video?

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

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.

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

(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.

Comment 7

[u279076]

(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.

Comment 8

[Matt Combs]

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?

Comment 9

[Matt Combs]

Test page updated per Anthony's request.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

(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.

Comment 11

[Matt Combs]

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!

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

Yeah, we should probably fix this so we're consistent with other implementations, and to avoid surprises for web devs.

Comment 13

[Justin Dolske [:Dolske]]

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?

Comment 14

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.