Fix a broken reftest.
The strong element has a different font weight by default. This means that the line height
is slightly different from the ref test. In normal Servo this doesn't matter due to how the
default snapping works.
However, in both WebRender and Firefox, this results in the reftests being one pixel different.
Setting the font weight to be normal makes the reftest pass in Servo, WebRender and FF.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9665)
<!-- Reviewable:end -->
Fix check to set flag if any header is a simple header.
Fix failing tests to allow merge in advance of @nikkibee's changes
as per @jdm's direction via IRC
The <strong> element has a different font weight by default. This means that the line height
is slightly different from the ref test. In normal Servo this doesn't matter due to how the
default snapping works.
However, in both WebRender and Firefox, this results in the reftests being one pixel different.
Setting the font weight to be normal makes the reftest pass in Servo, WebRender and FF.
This commit refactors the style crate to be completely independent of
the actual implementation and pseudo-elements supported.
This also adds a gecko backend which introduces parsing for the
anonymous box pseudo-elements[1], although there's still no way of
querying them.
https://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSAnonBoxList.h
Calculate correct mp4 header length.
The calculation of MP4 frame length is incorrect, shifting values by 1 bit instead of 8 bits. It works for the test MP4 file because the length of the frame is less than 256 bytes, so the shifted values are all zero.
This PR changes the code to calculate the length correctly. It adds a test to check a fake long stream. Still not long enough to test completely, but at least detects the problem with the original code.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9618)
<!-- Reviewable:end -->
Add a "mach test-wpt --chaos" mode for reproducing intermittent failures using rr
This adds a new `--chaos` flag to the `test-wpt` and `test-css` commands. This will run a test repeatedly until it fails, recording it with the rr debugger in chaos mode. Requires a recent master build of rr.
```
./mach test-wpt --chaos test.html
```
is shorthand for:
```
./mach test-wpt --repeat-until-unexpected \
--debugger rr \
--debugger-args "record --chaos" \
--include test.html
```
This PR currently includes changes to wptrunner which were also submitted upstream as w3c/wptrunner#170. We should not merge this until that upstream PR is merged. CC @jgraham
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9607)
<!-- Reviewable:end -->
Test filtered responses and implement Cors Check Fetch step
I've been writing tests for creating filtered responses. So far I have three of the four types being made (namely, Basic, CORS, and Opaque), and just need to figure out how to make an OpaqueRedirect filtered response, since it's handled separately from the others. I will also add more tests to ensure the content of the filtered responses matches the limitations placed by the specification.
Along the way I implemented Cors Check, since it's required for the CORS filtered response. @jdm suggested I handle it in here, since it's such a small step, compared to other parts of Fetch.
Since all the tests currently pass, and I've spent a while adding the Cors Check and other pieces, I figured now would be a good time to start having it reviewed.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9525)
<!-- Reviewable:end -->
mozbrowsersecuritychange event
Fixes#8544
No test yet. Is there a way to mock a https connection?
Also, I wish I could use the `HTTPSState` enum instead of a `String` when calling `trigger_mozbrowser_event` (https://github.com/servo/servo/compare/master...paulrouget:securitychange?expand=1#diff-30a18e04d7e0b66aafdf192e416cad44R306) but that would require `constellation_msg.rs` to know about `HTTPSState`, which is defined in `document.rs`, which would add a dependency to `components/msg`. I could define `HTTPSState` somewhere else maybe? Or maybe it's fine to use a `String`. But then, should I use the HTTPSState strings (`"modern/deprecated/none"`) or the mozbrowser strings (`"secure/insecure/broken"`) (as it is now)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9244)
<!-- Reviewable:end -->
Integrate compiletest_rs
This PR integrates `compiletest_rs` as suggested in #5646. I created a new `tests/compiletest` directory which contains separate crates for the tests.
Currently this PR includes `compile-fail` tests for some lints (acutally all except inheritance_integrity, beacuse I'm not sure how to include the dom stuff in a way the `#[dom_struct]` works).
I gathered that there should be more crates for which compiletests make sense and would appreciate any pointers to relevant crates.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9469)
<!-- Reviewable:end -->
