Currently, the spec doesn't seem to guarantee that the seeking flag is true at the time the seeking event is fired, although it's probably almost always the case in an implementation that follows the spec.

The problem is that the task queued to fire the seeking event could be run after the stable state is awaited, if "Wait until the user agent has established whether or not the media data for the new playback position is available, and, if it is, until it has decoded enough data to play back that position." happens fast enough, as it might for a resource which is short enough that its decoded data can be fully cached, like a short audio clip.

It's not news that state can have changed by the time the event is fired, but in this case simply queueing a task for the final 4 steps seems like a simple fix.

(I had already assumed that this would hold true in a test before I looked closer at the steps.)

Well we have to run the "time marches on" steps ASAP.

Why is it a problem that the attribute is in the accurate state when the event ends up getting run after the whole seeking thing is done? Surely it's a good thing; authors who know their stuff can just look to see what the attribute state is, and skip displaying the seeking UI.

In any case, we can't set the attribute on a task, because that would break the algorithm's reentrancy logic. We _could_ move the state to something other than the attribute, and have the attribute be less accurate but consistent with the events, but then it either couldn't change synchronously when you tried to seek, or you would end up in weird cases where the attribute changes to false for an earlier seek even though a later seek had already set it to true. That seems even more confusing.

Good points, I didn't consider how to abort the algorithm when seek() is called again. Since my simple fix doesn't work and I don't have another one that would, I'll resolve this as invalid.