1277554 - 'seeking' event on html5 video play is fired AFTER the seek operation is completed.

Status: RESOLVED INVALID

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

Description

[anurag2900]

What did you do?
================
1. Attached event listener 'seeking' on the video element
2. attached logs/break-points
3. wanted to get the time when the seek operation begins.

What happened?
==============
The callback for the 'seeking' event executes only after seek has completed.

What should have happened?
==========================
'seeking' should have fired as soon as seek starts, like in other browsers like chrome and safari.

Is there anything else we should know?
======================================
It works completely fine in Chrome and Safari

Comment 1

[:Gijs (he/him)]

Can you provide a testcase?

Comment 2

[Jean-Yves Avenard [:jya]]

What exactly do you mean by "timing"; how long it takes for the seek operation to complete or the time reported by the video?

Per spec:
https://w3c.github.io/html/semantics-embedded-content.html#seeking

The seeking event is *queued* right at the start (it is not fired immediately, as per step 10 of the spec); and the seeking operation start.
The seeking operation itself being asynchronous and running in parallel (as described in step 5), it is very well possible that the seeking has actually completed before the seeking event is actually fired and the event listener is executed.

If you really want to time the seeking operation, you can't use the time at which you are receiving the seeking event, but you need to time when you set the currentTime attribute. Anything else wouldn't be meaningful.

Comment 3

[anurag2900]

@Jean : How is this working for Chrome and Safari always without fail. And in Firefox, without fail, the 'seeking' event is fired after seek is complete. For that we already have the 'seeked' event. Makes no sense to have 'seeking' and 'seeked' doing the same thing.

Also i can get the video time at seek start by capturing the user click on timeline, but then i do not understand what 'seeking' is there for?

And to impress upon this one more time, it works completely fine on Chrome and Safari. Fails only on Firefox.

I will setup a test code and share it soon.

Comment 4

[anurag2900]

(In reply to Jean-Yves Avenard [:jya] from comment #2)
> What exactly do you mean by "timing"; how long it takes for the seek
> operation to complete or the time reported by the video?
> 
> Per spec:
> https://w3c.github.io/html/semantics-embedded-content.html#seeking
> 
> The seeking event is *queued* right at the start (it is not fired
> immediately, as per step 10 of the spec); and the seeking operation start.
> The seeking operation itself being asynchronous and running in parallel (as
> described in step 5), it is very well possible that the seeking has actually
> completed before the seeking event is actually fired and the event listener
> is executed.
> 
> If you really want to time the seeking operation, you can't use the time at
> which you are receiving the seeking event, but you need to time when you set
> the currentTime attribute. Anything else wouldn't be meaningful.

@Jean : How is this working for Chrome and Safari always without fail. And in Firefox, without fail, the 'seeking' event is fired after seek is complete. For that we already have the 'seeked' event. Makes no sense to have 'seeking' and 'seeked' doing the same thing.

Also i can get the video time at seek start by capturing the user click on timeline, but then i do not understand what 'seeking' is there for?

And to impress upon this one more time, it works completely fine on Chrome and Safari. Fails only on Firefox.

I will setup a test code and share it soon.

Comment 5

[Jean-Yves Avenard [:jya]]

Contrary to your belief; the seek event is queued immediately upon setting currentTime. As per spec. 

The problem I believe is that you incorrectly assume that if the seeking event is queued to be fired; your listener will be immediately called. That is not correct. 

Measuring the time between when you receive the seeking event and when you receive the seeked event is meaningless. You're not actually measuring the seeking operation. 

The only measurement that would make sense, as I suggested above; is the time between when currentTime is set and when the seeked event is received. 

This bug should be claimed as Invalid; as seeking is queued almost immediately.

Comment 6

[anurag2900]

(In reply to Jean-Yves Avenard [:jya] from comment #5)
> Contrary to your belief; the seek event is queued immediately upon setting
> currentTime. As per spec. 
> 
> The problem I believe is that you incorrectly assume that if the seeking
> event is queued to be fired; your listener will be immediately called. That
> is not correct. 
> 
> Measuring the time between when you receive the seeking event and when you
> receive the seeked event is meaningless. You're not actually measuring the
> seeking operation. 
> 
> The only measurement that would make sense, as I suggested above; is the
> time between when currentTime is set and when the seeked event is received. 
> 
> This bug should be claimed as Invalid; as seeking is queued almost
> immediately.

Thanks for that. I know seek event is queued immediately and i am doing that currently to measure the time.

I just want to know why is this behaviour different from chrome and safari? Also can you suggest me a usage of the 'seeking' event if what you say is happening?

Comment 7

[anurag2900]

(In reply to anurag2900 from comment #6)
> (In reply to Jean-Yves Avenard [:jya] from comment #5)
> > Contrary to your belief; the seek event is queued immediately upon setting
> > currentTime. As per spec. 
> > 
> > The problem I believe is that you incorrectly assume that if the seeking
> > event is queued to be fired; your listener will be immediately called. That
> > is not correct. 
> > 
> > Measuring the time between when you receive the seeking event and when you
> > receive the seeked event is meaningless. You're not actually measuring the
> > seeking operation. 
> > 
> > The only measurement that would make sense, as I suggested above; is the
> > time between when currentTime is set and when the seeked event is received. 
> > 
> > This bug should be claimed as Invalid; as seeking is queued almost
> > immediately.
> 
> Thanks for that. I know seek event is queued immediately and i am doing that
> currently to measure the time.
> 
> I just want to know why is this behaviour different from chrome and safari?
> Also can you suggest me a usage of the 'seeking' event if what you say is
> happening?

*seeking

Comment 8

[Jean-Yves Avenard [:jya]]

There are times seeking can't immediately complete. So it could take a while to receive the "seeked" event. 

There are cases, in particular with MediaSource extension, where seeking won't complete due to the lack of data to complete the operation.
You could also change currentTime while the readyState is HAVE_NOTHING, per spec the seeking event will only be queued once readyState change to HAVE_METADATA.

Knowing that seeking has started can be very useful too.

In any case, I can guarantee you that the seeking event isn't fired only once the seeking operation has completed.
I have a test case here, seeking into a big remote MP4, the time between seeking and seeked being received is almost 12 seconds.

You haven't provided a test case to reproduce the problem you describe, so I can't comment further on what you're seeing.