HTMLMediaElement sends 'seeking' and 'seeked' events from separate event queue that is not in sync with player callbacks. Seeking MSE video into buffered range may complete the seek (by m_player->timeChanged()) faster then 'seeking' event is dispatched to JavaScript. They both runs on the same main thread but different queues. As a result JavaScript is not able to notice video.seeking property (as it is 'false' again when 'seeking' event reaches JavaScript).
The solution is taken from audio-only streams https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1232
and extended for video also. It puts timeChanged() notification on HTMLMediaElement event queue, the same that keeps JavaScript events to make sure everything is in sync.
calvaris
commented
2 days ago
HTMLMediaElement sends 'seeking' and 'seeked' events from separate event queue that is not in sync with player callbacks. Seeking MSE video into buffered range may complete the seek (by m_player->timeChanged()) faster then 'seeking' event is dispatched to JavaScript. They both runs on the same main thread but different queues. As a result JavaScript is not able to notice video.seeking property (as it is 'false' again when 'seeking' event reaches JavaScript).
The solution is taken from audio-only streams https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1232 and extended for video also. It puts timeChanged() notification on HTMLMediaElement event queue, the same that keeps JavaScript events to make sure everything is in sync.
This works around and issue from https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1347
PS. I think https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1211 is not needed any more because of https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1338 and current didPreroll() implementation. But I don't have initial test case to confirm.