Set the expected result of the test `tex-input-validation.html` to CRASH, since
that is caused by unrelated problems. The test was previously not executing
completely, because it stopped when it didn't find the implementation of
getTexParameter.
This makes rowspan=0 work by storing notes on which group of rows we're
in for tables containing both rowgroups and rows, and using that to
respan cells with overlarge or zero rowspans.
This also gets rid of the largest_leftover_incoming_size business,
because now spans will always be correct and we'll never have any left
over.
Rowspan support for tables
fixes#20092
This just contains the first steps.
We apply a naive algorithm: Spanning cells apply a pressure equal to `block_size / rowspan` on each row they are in. We move table row block size computation into the tables, and make it two pass. In the first pass we compute the sizes of each row, and in the
second pass we assign them, adding them up for any involved cells.
This is missing:
- [x] Accounting for border sizes
- [x] Applying pressure to rows that are not the row containing the cell
- [ ] Reducing pressure on future rows if the current row is able to accomodate more of the cell
- [x] For tables containing both rows and rowgroups, reset the rowspan info when we hit a rowgroup
- [x] Correctly handle overflowing rowspans
cc @mbrubeck @pcwalton
<!-- 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/20128)
<!-- Reviewable:end -->
Avoid `Window::GetComputedStyle` when checking for `display: none`
<!-- Please describe your changes on the following line: -->
Refactored Window::GetComputedStyle to use Element::Style.
Not sure which tests are relevant, but I've ran the dom, fetch & 2dcontext wpt tests. They don't seem to give errors.
---
<!-- 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#19885.
<!-- Either: -->
- [x] These changes do not require tests because it's a refactoring task
<!-- 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/20012)
<!-- Reviewable:end -->
Browsing context names
<!-- 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: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix https://github.com/servo/servo/issues/14453
<!-- 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/20036)
<!-- Reviewable:end -->
Disallow mutating the internals of TextInput
The TextInput::assert_ok_selection() method is meant to ensure that we
are not getting into a state where a selection refers to a location in
the control's contents which doesn't exist.
However, before this change we could have a situation where the
internals of the TextInput are changed by another part of the code,
without using its public API. This could lead to us having an invalid
selection.
I did manage to trigger such a situation (see the test added in this
commit) although it is quite contrived. There may be others that I
didn't think of, and it's also possible that future changes could
introduce new cases. (Including ones which trigger panics, if indexing
is used on the assumption that the selection indices are always valid.)
The current HTML specification doesn't explicitly say that
selectionStart/End must remain within the length of the content, but
that does seems to be the consensus reached in a discussion of this:
https://github.com/whatwg/html/issues/2424
The test case I've added here is currently undefined in the spec which
is why I've added it in tests/wpt/mozilla.
<!-- 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/20051)
<!-- Reviewable:end -->
wpt tests replace all but 3 tests from forked _mozilla_ tests. These 3 were removed from wpt repo
in commit de7719144e1c7da2ca8d6a543bec428fcfd3c30f, so we can remove all forked _mozilla_
css-paint-api tests
The TextInput::assert_ok_selection() method is meant to ensure that we
are not getting into a state where a selection refers to a location in
the control's contents which doesn't exist.
However, before this change we could have a situation where the
internals of the TextInput are changed by another part of the code,
without using its public API. This could lead to us having an invalid
selection.
I did manage to trigger such a situation (see the test added in this
commit) although it is quite contrived. There may be others that I
didn't think of, and it's also possible that future changes could
introduce new cases. (Including ones which trigger panics, if indexing
is used on the assumption that the selection indices are always valid.)
The current HTML specification doesn't explicitly say that
selectionStart/End must remain within the length of the content, but
that does seems to be the consensus reached in a discussion of this:
https://github.com/whatwg/html/issues/2424
The test case I've added here is currently undefined in the spec which
is why I've added it in tests/wpt/mozilla.
This allows servo to use the ExternalScrollId API from WebRender fixing
some issues related to duplicate scroll root ids.
Fixes#17176.
Fixes#19287.
Fixes#19648.
WPT tests: Remove custom cache script, use trickle option instead
<!-- Please describe your changes on the following line: -->
Follow up on https://github.com/servo/servo/pull/19350 @jdm
---
<!-- 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/19849)
<!-- Reviewable:end -->
Ignore aborted responses in caching
<!-- Please describe your changes on the following line: -->
@jdm @KiChjang @Manishearth Follow up on https://github.com/servo/servo/pull/18676 and https://github.com/servo/servo/pull/19274 to ignore aborted responses in caching.
I also found out the cache shouldn't return any response whose body is still in `ResponseBody::Receiving` mode, because that fails the assertion at https://github.com/servo/servo/blob/master/components/net/fetch/methods.rs#L438(we might want to add a channel as pat of the cached response later on to deal with this case). I only found out now because I needed the response from the server to trickle in so that it could be cached and aborted.
I copied the `http-cache.py` server from the wpt folder, and added a 'trickle' option, which is necessary to actually have a failing test with a cached but aborted request, it's now passing.
I also remove one unused import that slippled through previously.
---
<!-- 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/19350)
<!-- Reviewable:end -->
Root sequence<any> params using CustomAutoRooter
<!-- Please describe your changes on the following line: -->
Attempt at https://github.com/servo/servo/issues/16678. At the moment this pulls an external [remove-handle-conv](https://github.com/Xanewok/rust-mozjs/tree/remove-handle-conv) branch for rust-mozjs (removing `FromJSValConvertible` implementation for `HandleValue` and adding one for `*mut JSObject`)
In short, this roots the `sequence<any>` and `sequence<object>` function arguments using `CustomAutoRooter` (introduced in https://github.com/servo/rust-mozjs/pull/382).
As per https://github.com/servo/servo/issues/16678#issuecomment-302224110 the underlying vector contains raw gc thing pointers instead of handles. To do that, this introduces new possible `isMember = "AutoRoot"` value in CodegenRust.py.
The rooted argument is passed to a function wrapped in a `CustomAutoRooterGuard` [RAII root guard](ed5e37a288/src/rust.rs (L586-L588)) (e.g. as `CustomAutoRooterGuard<Vec<JSVal>>`)
I felt quite out of my depth when trying to adapt CodegenRust.py code, so I'd appreciate any help with how can be done better/in a more clean manner.
Also the name `CustomAutoRooterGuard` is quite lengthy, so I'm also open to changing it (`AutoRoot`? `AutoRootGuard`?)
---
<!-- 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#16678 (github issue number if applicable).
<!-- Either: -->
- [X] 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/19644)
<!-- Reviewable:end -->
Fixes#19631
Since the addition of timeouts to paint worklets, CSS paint API threads
were failing intermittently because of the timeouts being fired. This is
because the timeouts are quite tight, to account for the 60fps
requirement. Bumping up the timeout threshold for these tests alone is
the easiest solution.
In aa48a2c2e3 I added a timeout for paint
worklet threads. However, the test was broken. The blocking sleep
function that was implemented as part of that commit was guarded behind
the `dom.worklet.blockingsleep.enabled` pref, and while I ran the
wpt-tests with that pref enabled, the test runner for sure did not.
I tried running the test _without_ the pref enabled, and the tests still
pass. This is because even the reference in that reftest is that of
a broken image background, and *both* the paintworklet thread timing out
and `sleep()` not being in scope would render the same thing: a broken
image, which compares equal to the reference.
This patch makes sure that now the pref is enabled for wpt worklet
tests, and that such we can distinguish an actual timeout (test pass)
from an unexpected situation (when we should fail the test).
When a paint worklet thread takes too long, we would like to move on,
since we have a ~16ms budget for rendering @60fps. At the moment, there
is no provision in the paintworklet spec to signal such timeouts to the
developer. ajeffrey opened an [issue][1] for this, but it got punted to
v2 of the spec. Hence we are silently timing out unresponsive paint
scripts.
The timeout value is chosen to be 10ms by default, and can be overridden
by setting the `dom.worklet.timeout_ms` pref.
In the absence of such a timeout, the reftest in this commit would fail
by timing out the testrunner itself, since the paint script never
returns. From my discussions with ajeffrey, this should do until we spec
out a way to signal timeouts to the script developer.
Since we did not have a better way to trigger a timeout than a busy
waiting loop (which would hog one core of the test machine until the
timeout was reached), we decided to implement a test only blocking
sleep, available to the PaintWorkletGlobalScope. Since
`dom.worklet.enabled` enables worklets in general, we also decided to
have another pref `dom.worklet.blockingsleep.enabled`, which, in
addition to `dom.worklet.enabled`, would be required for the blocking
sleep to be available.
This fixes#17370.
[1]: https://github.com/w3c/css-houdini-drafts/issues/507
DOMMatrix needs to convert a specified transform list into a matrix, so
we could rewrite to_transform_3d_matrix by generics for both specified
and computed transform lists.
Besides, we have to update the test case because we use Transform3D<f64> to
compute the matrix, instead of Transform3D<f32>, so the result will be
the same as that in Gecko. Using 0.3 may cause floating point issue
because (0.3f32 as f64) is not equal to 0.3 (i.e. floating point precision
issue), so using 0.25 instead.
