The following IDLs have the src/href attributes typed as a DOMString
while in the spec the attribute has been updated to be a USVString:
- HTMLIFrameElement
- HTMLImageElement
- HTMLInputElement
- HTMLLinkElement
- HTMLMediaElement
- HTMLScriptElement
Improve implementation of media resource fetch algorithm
I have been observing inconsistent behaviors with my local tests depending of the media asset being played. I figured that we had these issues:
- We were setting the player EOS as soon as we got the first [process_response_eof](1046ae58a1/components/script/dom/htmlmediaelement.rs (L1596)). This is fine only if there is a single request. But that's not the case for multiple range requests or for seeks. Setting the player EOS makes the player appsrc reject any new buffers, and that breaks playback. Figuring out when is the right time to set the player EOS won't be a straight forward task, so my suggested fix for now is to simply not set it for now. It is a cleanup step that it would be nice to have but it is not mandatory.
- We were setting the input size more than once for multiple range requests and with the incorrect value. The fix uses the `content-length` or the `content-range` headers for single and range requests respectively.
- We were moving to the HaveEnoughData state if a fetch request succeded but no data was fetched from the network.
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22433)
<!-- Reviewable:end -->
refactoring with ResourceFetchMetadata
implemented deprecated window.timing functionality
created ResourceTimingListener trait
fixed w3c links in navigation timing
updated include.ini to run resource timing tests on ci
I moved away from the `Window` struct all the logic to handle task
sources, into a new struct called `TaskManager`. In a happy world, I'd
be able to just have there two functions, of the types:
```rust
fn task_source<T: TaskSource>(&self, name: TaskSourceName) -> Box<T>
fn task_source_with_canceller<T: TaskSource>(&self, name: TaskSourceName)
-> (Box<T>, TaskSourceCanceller)
```
And not so much duplicated code. However, because TaskSource can't be a
trait object (because it has generic type parameters), that's not
possible. Instead, I decided to reduce duplicated logic through macros.
For reasons[1], I have to pass both the name of the function with
canceller and the name of the function without, as I'm not able to
concatenate them in the macro itself. I could probably use
`concat_idents` to create both types already defined and reduce the
amount of arguments by one, but that macro is nightly only. At the same
time, not being able to declare macros inside `impl` forces me to pass
`self` as an argument.
All this makes this solution more verbose than it would be ideally. It
does reduce duplication, but it doesn't reduce the size of the file.
[1](https://github.com/rust-lang/rust/issues/29599)
HTMLMediaElement - use media element instead of dom manipulation task…
… source
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22129)
<!-- Reviewable:end -->
The spec has a complicated algorithm for selecting a <source>
element among multiple <source> children of a HtmlMediaElement
where it loops over all of them, tries each and takes the first
where "everything works out".
This commit implements a much simpler and restricted approach by
just taking the first <source> child, and if that fails,
failing altogether, without looking at any further children.
This is an improvement over the current status and makes gifv
items on imgur playable, although it doesn't mean full <source>
support.
Since media processing is highly asynchronous, there is no need to
match one event with the other. Then error handling is done when
the player emits the EOS event.
The have_metadata attribute is not required anymore.
