<!-- Please describe your changes on the following line: -->
* components/script/dom/servoparser/mod.rs updated to handle application/xml as text/xml, along with hoisting application/xhtml+xml from the unknown mime types match arm.
* tests updated via mach
---
<!-- 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#15850 (github issue number if applicable).
<!-- Either: -->
- [X] These changes modify results in test files via the automated: `./mach test-wpt tests/wpt/web-platform-tests/dom/nodes --log-raw /tmp/servo && ./mach update-wpt /tmp/servo`
- [ ] 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. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 60dca9cc4418b1cd0c21bee89d7b0d0bf657a7ff
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bf51aededee6d51b599717c0b31c29e49c17dce6
This is a sub-PR of #19015
r? @emilio
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19276
- [x] These changes do not require tests
Source-Repo: https://github.com/servo/servo
Source-Revision: 011e52f6ed06f260c4756a4c8fd04d4cc7912839
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 856d379ee399e0e33a43b695678cdc0ec668f2f4
This is important because it ensures we release the shared memory handle
(although not the data itself) for the underlying surface buffer when it
turns out we will probably never need to share it. If we do need to
share the surface data with the GPU process, it will reallocate a handle
if necessary, and close it when it is finished. On some platforms we
only have a finite number of handles, so if we don't need them, we
should close them.
This is largely trivial because the meat of the implementation is
located in ImageResource and we already added GetFrameInternal.
Interestingly VectorImage::IsUnlocked does not actually check if the
image is locked, but instead only checks for animation consumers. This
is consistent with its historical behavior on when to issue an unlocked
draw event.
Note that we do not implement the original GetImageContainer and
IsImageContainerAvailable APIs. This is because the former does not
accept an SVG context and it would be best to discourage its use in old
code lest we get incorrect/unexpected results.
No functional change aside from the implementation from
VectorImage::GetFrameAtSize being repurposed for GetFrameInternal and
returning an additional error code with the surface.
Creating a DrawTarget can be an expensive operation. This is especially
true in this case because checking for a cached already decoded version
of the VectorImage is expected to be fast. Currently VectorImage::Draw
is the typical path to render these images, but in the future, getting
the frames directly or indirectly (through an ImageContainer) will
become more common.
This adds the code that APZ needs to use the WR hit-testing API. For now
(if the pref is enabled) it just does the hit-test and compares the
result to the regular hit-test, printing out discrepancies. It also
doesn't yet get the scrollbar result.
MozReview-Commit-ID: 3pjYSWDGeDr
--HG--
extra : rebase_source : 9766fe3e77dd85f130ce155041cec7c0daae67ec
It seems like a footgun to expose raw pointers to WebRenderAPI which is
a refcounted object. Let's only expose it via refcounting pointers.
MozReview-Commit-ID: AKmTZg2V99r
--HG--
extra : rebase_source : 805f13d56a64bafbcdf3bf4266eec47c70856564
These days (at least with webrender enabled), the layers id is created
by mashing together two uint32 values into the uint64. Printing it as in
base 10 produces some large number near the 32-bit boundary, and it's
much more legible/easier to compare when printed in hex.
MozReview-Commit-ID: JsGhqyLtDBv
--HG--
extra : rebase_source : ed60d26d8223d968f37e8d933e60b1ee6552d1e9
We only label Object as being ArrayLike if they have consecutive, numeric indexes, starting at 0,
and that could contain only a non-numeric length property that matches the actual number of numeric
keys in the object.
A test is added to make sure we don't regress this.
Fix old console frontend tests which relied on the bad implementation of ArrayLike (and delete
test cases now covered by the server test).
MozReview-Commit-ID: ATF7WypNVhh
--HG--
extra : rebase_source : 5e6a0ef0da84cf89518164f518a257bd1f0d5fd8
Update known requirements for building.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19238.
Source-Repo: https://github.com/servo/servo
Source-Revision: b2b51d333e99c1d2a7322ae53357f2b095ba2d40
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 7a8a1c0a960f0d7fd1309a29c90fde9cea8a17f8
