Unify background placement code
Merges the implementations for background-image placement
from gradients and images. Add missing parts and fix bugs.
Now supported are the CSS properties:
* background-attachment (except for local value, see #19650)
* background-clip
* background-origin
* background-position-x/y
* background-repeat
* background-size
It should be noted that backgrounds are not clipped to
rounded border corners.
(This was done before but worked only in simple cases)
See: #19649
This solves the following issues:
closes#19626closes#16657closes#19482 (examples from http://lea.verou.me/css3patterns/ are rendered perfectly but the round border is completely ignored now)
closes#19577
- `./mach build -d` does not report any errors
- `./mach test-tidy` does not report any errors
I enabled a few tests with the first commit but I have written about a dozen manual tests I will try to turn into ref tests either before or after this patch lands.
@bors-servo try
The relationship between the different inputs is visualized in this flowchart:
<!-- 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/19651)
<!-- Reviewable:end -->
Merges the implementations for background-image placement
from gradients and images. Add missing parts and fix bugs.
Now supported are the CSS properties:
* background-attachment (except for local value)
* background-clip
* background-origin
* background-position-x/y
* background-repeat
* background-size
It should be noted that backgrounds are not clipped to
rounded border corners.
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
implement valid week string
<!-- Please describe your changes on the following line: -->
implement valid week string
part of #19172
r? @KiChjang
---
<!-- 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] There are tests for these changes
<!-- 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/19559)
<!-- Reviewable:end -->
layout: background-origin attribute for gradients
Fixes the glitches mentioned in #19554.
Now gradient tiles are placed in the whole bounding box.
<!-- 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
<!-- Either: -->
- [X] There are tests for these changes
<!-- 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/19568)
<!-- Reviewable:end -->
Add a topLevelDomComplete metric.
<!-- Please describe your changes on the following line: -->
Measure DOM completion without iframes. This is in support of measuring when the main document is loaded, ignoring secondary content, e.g. ads.
---
<!-- 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#19561
- [X] There are tests for these changes
<!-- 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/19569)
<!-- Reviewable:end -->
Use background-size, background-position properties to render
CSS gradients.
Some cleanup in display_list_builder.rs related to gradient
calculations.
Adds two wpt tests for tiled gradients.
Note: For now even gradients with background-repeat: no-repeat
are repeated. Sometimes the gradient is not repeated everywhere.
Enable vars-background-shorthand-001.html CSS test.
Handle cases where selection API doesn't apply
The selection API only applies to certain <input> types:
https://html.spec.whatwg.org/multipage/#do-not-apply
This commit ensures that we handle that correctly.
Some notes:
1. TextControl::set_dom_selection_direction now calls
set_selection_range(), which means that setting selectionDirection will
now fire a selection event, as it should per the spec.
2. There is a test for the firing of the select event in
tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html,
however the test did not run due to this syntax error:
(pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration"
This happens due to the us of the "for (const foo of ...)" construct.
Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of
this should actually work, so it's somewhat unsatisfying to have to
change the test.
3. I removed tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea.html
because it doesn't seem to add any extra value - the selection API
always applies to textarea elements, and the API is tested elsewhere.
4. If an `<input>`'s type is unset, it defaults to a text, and the
selection API applies. Also, if an `<input>`'s type is set to an
invalid value, it defaults to a text too. This second case doesn't
currently work, and I'll need to do more restructuring of the code in
a future commit. See discussion with nox in IRC:
https://mozilla.logbot.info/servo/20171201#c13946454-c13946594
<!-- 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/19461)
<!-- Reviewable:end -->
The selection API only applies to certain <input> types:
https://html.spec.whatwg.org/multipage/#do-not-apply
This commit ensures that we handle that correctly.
Some notes:
1. TextControl::set_dom_selection_direction now calls
set_selection_range(), which means that setting selectionDirection will
now fire a selection event, as it should per the spec.
2. There is a test for the firing of the select event in
tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html,
however the test did not run due to this syntax error:
(pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration"
This happens due to the us of the "for (const foo of ...)" construct.
Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of
this should actually work, so it's somewhat unsatisfying to have to
change the test.
4. If an <input>'s type is unset, it defaults to a text, and the
selection API applies. Also, if an <input>'s type is set to an
invalid value, it defaults to a text too. I've expanded the tests
to account for this second case.
Expand InputType to cover all possible types
This came out of a conversation with nox in IRC:
https://mozilla.logbot.info/servo/20171201#c13946454-c13946594
The code I was working on which motivated this change is here:
https://github.com/servo/servo/pull/19461
Previously, InputType::Text was used to represent several different
values of the type attribute on an input element.
If an input element doesn't have a type attribute, or its type attribute
doesn't contain a recognised value, then the input's type defaults to
"text".
Before this change, there were a number of checks in the code which
directly looked at the type attribute. If those checks matched against
the value "text", then they were potentially buggy, since an input with
type=invalid should also behave like an input with type=text.
Rather than have every conditional which cares about the input type also
have to deal with invalid input types, we can convert the type attribute
to an InputType enum once, and then match against the enum.
A secondary benefit is that the compiler can tell us whether we've
missed branches in a match expression. While working on this I
discovered that the HTMLInputElement::value_mode() method misses a case
for inputs with type=hidden (this resulted in a failing WPT test
passing).
I've also implemented the Default trait for InputType, so we now only
have one place in the code which knows that InputType::Text is the
default, where previously there were several.
<!-- 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/19471)
<!-- Reviewable:end -->
This came out of a conversation with nox in IRC:
https://mozilla.logbot.info/servo/20171201#c13946454-c13946594
The code I was working on which motivated this change is here:
https://github.com/servo/servo/pull/19461
Previously, InputType::Text was used to represent several different
values of the type attribute on an input element.
If an input element doesn't have a type attribute, or its type attribute
doesn't contain a recognised value, then the input's type defaults to
"text".
Before this change, there were a number of checks in the code which
directly looked at the type attribute. If those checks matched against
the value "text", then they were potentially buggy, since an input with
type=invalid should also behave like an input with type=text.
Rather than have every conditional which cares about the input type also
have to deal with invalid input types, we can convert the type attribute
to an InputType enum once, and then match against the enum.
A secondary benefit is that the compiler can tell us whether we've
missed branches in a match expression. While working on this I
discovered that the HTMLInputElement::value_mode() method misses a case
for inputs with type=hidden (this resulted in a failing WPT test
passing).
I've also implemented the Default trait for InputType, so we now only
have one place in the code which knows that InputType::Text is the
default, where previously there were several.
Call children_changed on the parent node consistently
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19177
- [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/19384)
<!-- Reviewable:end -->
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.
Handle arraybuffer responseType in XHR
<!-- Please describe your changes on the following line: -->
Handle arraybuffer responseType in XHR
---
<!-- 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
- [ ] These changes fix #__ (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/19352)
<!-- Reviewable:end -->
I had to change the test a little bit to avoid some failures due to
color and text both having a sanitizedValue which was making the test
use the first assertion instead of the second one in some cases.
The sanitize_value implementation is pretty simple, we iterate over the
content and checks that the content is 7 characters long, that the first
character is a `#` and then that all the following characters are
hexadecimal. If all those requirements are met, we lowercase the
content, otherwise we put `#000000` in it.
Absolutely replaced elements with padding were incorrectly setting their
block size to include twice the padding values. This attempts to stop
that extra padding for replaced elements but leave the working flow for
non replaced elements
Make wdspec tests runnable
This makes it possible to run tests in tests/wpt/web-platform-tests/webdriver/tests and focus on investigating why they fail.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix (partially) #15274.
- [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/19318)
<!-- Reviewable:end -->
Continue http cache work
<!-- Please describe your changes on the following line: -->
Work in progress, and not quite worth a review yet. (Continuation of https://github.com/servo/servo/pull/4117)
TODO
- [ ] cache metadata (find some subset of`net_traits::Metadata` that can be shared across threads, it seems the problem is mainly stuff inside `hyper::header` in the `headers` field)
- [ ] determine which other fields of a `Response` need to be cached, so a full and valid one can be returned upon a cache hit.
- [ ] determine how to best share the cache across fetch threads (inside HttpState like I tried now?)
- [ ] Spend more time reading the spec and make sure the cache follows it where it matters.
- [ ] Make the current wpt tests pass.
- [ ] More...
---
<!-- 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#12972 (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/18676)
<!-- Reviewable:end -->
Update expected results for hash-name-reference.html.
These are stable expected results, and we missed them because the test is marked as intermittent in #16179.
<!-- 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/19270)
<!-- Reviewable:end -->
