Avoid sending idle message more than once after a reflow is complete
<!-- Please describe your changes on the following line: -->
A boolean variable is introduced to prevent sending SetDocumentState idle message multiple times after a reflow is complete.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#22410 (GitHub issue number if applicable)
<!-- Either: -->
- [x] These changes do not require tests because automated test is not possible.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- 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/22451)
<!-- Reviewable:end -->
Fix DuckDuckGo HTML search
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#22090
- [x] There are tests for these changes
<!-- 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/22354)
<!-- Reviewable:end -->
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 -->
Add onmessageerror to WindowEventHandler
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- 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/22081)
<!-- Reviewable:end -->
Cancel animations that affect nodes that do not participate in layout.
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#22378
- [x] There are tests for these changes
<!-- 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/22389)
<!-- Reviewable:end -->
Fix missing textures on reloading three.js image content
The fundamental problem is that three.js sets the crossOrigin property of an image, which kicks off an image microtask, and then sets the src. When the image URL is in the image cache (such as when reloading a page), this causes the shortcut to be taken and the image data is made available immediately, but the queued image task is unaware of this and asks the image cache to feed the image data. The existing code then ended up in an unexpected state when trying to deal with this data, such that when three.js received the image load notification and performed the texImage2D operation on the image data, it would discover that the image element did not claim to have a URL, and it would treat this as a broken image. Ultimately, this caused the texture that three.js obtained to be completely black.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#22152.
<!-- 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/22336)
<!-- Reviewable:end -->
