script: Implement fetching request for track elements - #46289
Merged
Conversation
|
🔨 Triggering try run (#28751756328) for Linux (WPT) |
Contributor
Author
|
I started implementation after investigating missing test coverage for |
|
Test results for linux-wpt from try job (#28751756328): Flaky unexpected result (33)
Stable unexpected results that are known to be intermittent (21)
Stable unexpected results (68)
|
|
|
TimvdLippe
force-pushed
the
implement-text-track-fetching
branch
2 times, most recently
from
July 6, 2026 07:06
547e2b3 to
29443cd
Compare
mrobinson
approved these changes
Jul 7, 2026
Comment on lines
+153
to
+155
| // Step 8. ⌛ If the track element's parent is a media element, | ||
| // then let corsAttributeState be the state of the parent media element's | ||
| // crossorigin content attribute. Otherwise, let corsAttributeState be No CORS. |
Member
There was a problem hiding this comment.
This looks like a spec issue? We've returned in step 3 if the parent wasn't a media element.
Contributor
Author
There was a problem hiding this comment.
Well, I am not sure yet how to read the spec here. I think the spec means "this step might run asynchronously and at that point the parent might no longer be a media element". I was planning on asking WHATWG on how to read the spec and then get back to it.
Member
There was a problem hiding this comment.
Oh, good point. This makes sense.
Comment on lines
+275
to
+277
| // Step 3. If value is not the empty string, | ||
| // then set trackURL to the result of encoding-parsing-and-serializing a URL given value, | ||
| // relative to the element's node document. |
Member
There was a problem hiding this comment.
Do you mind rewrapping this so that line length is more consistent? When all lines flow together without newlines, it is very hard to see where one step starts and another begins with inconsistent line lengths. Editors almost always have rewrapping functionality to do this automatically.
Contributor
Author
There was a problem hiding this comment.
Unfortunately I use VS Code which doesn't appear to do auto-wrapping of text comments. I have updated this text and done my best here to make it readable.
Member
There was a problem hiding this comment.
Odd. The vim keybindings in VS Code support this out of the box, but the Rewrap extension seems to do it as well.
Contributor
Author
There was a problem hiding this comment.
Can we consider turning on wrap_comments on rustfmt to do this automatically for us? rust-lang/rustfmt#3347
Member
There was a problem hiding this comment.
Sounds good to me. I'm not sure it would handle the case where a line was shorter than expected, but it would be an improvement.
Comment on lines
+459
to
+462
| // > If fetching 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 an event named load at the track element. |
Member
There was a problem hiding this comment.
I assume that processing here refers to parsing a subtitle file or something of that nature?
Contributor
Author
There was a problem hiding this comment.
Yes it is part of the first paragraph of step 10 of https://html.spec.whatwg.org/multipage/media.html#start-the-track-processing-model
The tasks queued by the fetching algorithm on the networking task source to process the data as it is being fetched must determine the type of the resource. If the type of the resource is not a supported text track format, the load will fail, as described below. Otherwise, the resource's data must be passed to the appropriate parser (e.g., the WebVTT parser) as it is received, with the text track list of cues being used for that parser's output. [WEBVTT]
| pub(crate) fn tracks_for_kinds( | ||
| &self, | ||
| text_track_kinds: Vec<TextTrackKind>, | ||
| ) -> Vec<DomRoot<TextTrack>> { |
Member
There was a problem hiding this comment.
You might be able to avoid an allocation here by returning impl Iterators<Item=DomRoot<TextTrack>> and then avoiding the collect(). The caller will have to be a bit careful because all() / any() have tricky semantics when an iterators is empty. I think it might be worth it though.
Contributor
Author
There was a problem hiding this comment.
Yeah I did consider it, but am not yet well-versed with Rust iterators yet. I will get back to this when we need to implement sorting (https://html.spec.whatwg.org/multipage/media.html#list-of-text-tracks) which we don't do yet. The sorting would fit nicely with an iterator I think.
Contributor
Author
|
Thank you so much for taking the time to review this @mrobinson ! |
This is the first step of support for track elements. Now, at the appropriate times, a request is sent out. The result of the request is ignored for now, since this PR is already big enough of its own. To do so, a text track needs to keep track of whether it is part of a track element. Then, at the various decision points, it starts the processing model. This is mostly implemented in terms of machinery, but not all of its parallel steps. That's because I have yet to figure out what they actually mean with "wait until X", whether that just means to reboot the algorithm or not. Part of servo#46288 Testing: new WPT tests passing/running. Signed-off-by: Tim van der Lippe <tvanderlippe@gmail.com>
TimvdLippe
force-pushed
the
implement-text-track-fetching
branch
from
July 7, 2026 09:46
29443cd to
548c383
Compare
TimvdLippe
enabled auto-merge
July 7, 2026 09:46
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the first step of support for track elements. Now, at the appropriate times, a request is sent out. The result of the request is ignored for now, since this PR is already big enough of its own.
To do so, a text track needs to keep track of whether it is part of a track element. Then, at the various decision points, it starts the processing model. This is mostly implemented in terms of machinery, but not all of its parallel steps. That's because I have yet to figure out what they actually mean with "wait until X", whether that just means to reboot the algorithm or not.
Part of #46288
Testing: new WPT tests passing/running.