Closed Bug 882669 Opened 11 years ago Closed 2 years ago

[webvtt] Ensure that the loadedmetadata event is being dispatched correctly

Categories

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

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: reyre, Unassigned)

References

()

Details

One of the conditions on when to dispatch this event is having the text tracks ready to be displayed. We need to ensure this happens.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
When this gets in place we can remove the code in the track tests that wait for the track's mode to be the correct value, and instead, just depend on the 'loadedmetadata' event.
Assignee: nobody → rick.eyre
Depends on: 882718
No longer depends on: 882718
My mistake. This does depend on bug 882718 as PopulatePendingTextTrackList needs to be called from the algorithm in bug 882718 and the dispatching of the loadedmetadata event depends on that list.
Depends on: 882718
@Rick
I'm not absolutely sure, wether this is correct. I thought the loadedmetadata is only for the mediaelement itself and not for the associated tracks elements. At least track elements in the disabled state shouldn't load before the document is completed. Current versions of FF are loading all tracks upfront, which isn't really good for network performance. Even if a track has a 'default' flag or its mode was changed by script fetching can be deferred after document is complete or as soon as the video's paused state changes to false. 

While delaying the loadedmetadata event until all track elements with default flag are loaded might be reasonable, it doesn't fit for the other track elements.

Something that is quite important here, is to implement the 'readyState' property in conjunction with the 'load' and the 'error' event. See also the spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#honor-user-preferences-for-automatic-text-track-selection
"If the fetching algorithm does not fail, and the file was successfully processed, then the final task that is queued by the networking task source, after it has finished parsing the data, must change the text track readiness state to loaded, and fire a simple event named load at the track element."

A callback function, which honors the async behavior of loading tracks, could look like this:

	function onTrackReady(){
		if(this.readyState > 1){

			if(this.readyState == 2){
				//handle textTracks because thier are now ready
			}

			//remove listener because track is either loaded or has an error
			this.removeEventListener('load', onTrackReady);
			this.removeEventListener('error', onTrackReady);
		}
	}

	Array.prototype.slice.call(document.querySelectorAll('video > track')).forEach(function(track){
		track.addEventListener('load', onTrackReady);
		track.addEventListener('error', onTrackReady);
		onTrackReady.call(track);
	});

BTW.: I really appreciate your hard work on this upcomming feature. Can't wait to see it in production!
Hey Alexander,

No problem! Thanks for your input on the readiness of Firefox's implementation of WebVTT. It's been very valuable and helpful :-).

The loadedmetadata event has now been changed to also require the text tracks to be ready to fire. See here http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#event-media-loadedmetadata

I'm not sure if your suggestion to defer the loading of tracks to when they're needed is a good idea. Since loadedmetadata has changed to now mean that the tracks have been loaded and everything is ready to go we need to support this functionality. This is important in the case where script might want to manipulate the track data that has been loaded. We can't always wait until the track has been set to showing to load it since script could want to manipulate the track data before that time. It also means that once script has received the loadedmetadata event that it is safe to manipulate track data.

There are also a few other considerations--waiting until the user clicks play to load the track might result in lag where none would be expected (since the video has already buffered the video stream). Also, from my understanding this change wouldn't be a trivial fix due to the way that Gecko loads resources.

The readystate events should be working. I thought I tackled that in bug 882677. Let me know if you're having trouble getting it to work on nightly.
Hi Rick,

just saw your answer now. Thanks for the update about the loadedmetadata event. Really didn't know. To be honest I think this spec change isn't that good. If I want to manipulate a track by script, I can set it from disabled to hidden and wait for the load event. In case a mediaelement has preload set to "" or "auto" I can understand preloading also it's track files because author thinks the video will be likley played.

Just tested bug 882677 seems that there is inly a small typo 'loaded' instead of 'load' to have this work.

Thanks again. Seems, that I have to update my polyfill ;-).
(In reply to Alexander Farkas from comment #5)

> Just tested bug 882677 seems that there is inly a small typo 'loaded'
> instead of 'load' to have this work.

Just saw that and will be fixing it. Thanks for the testing :-)!
Component: Audio/Video → Audio/Video: Playback
Rank: 15
Priority: -- → P2

The bug assignee didn't login in Bugzilla in the last 7 months.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: rick.eyre → nobody
Flags: needinfo?(jmathies)
Status: REOPENED → RESOLVED
Closed: 11 years ago2 years ago
Flags: needinfo?(jmathies)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.