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 -->
Make iframes block the enclosing document's load event
It occurs to me as I write this that this doesn't handle the case of removing the iframe from the document before it's finished loading. Consider this an early feedback release!
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6677)
<!-- Reviewable:end -->
In cases where a pending parser-blocking script is executing, if the script
caused another load to complete (eg. by removing a pending iframe from the
DOM, thus terminating the load) then the currently-executing script would
attempt to execute itself again.
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 -->
Add CI script to retry builds
We can then run test-ref as `retry.sh 2 ./mach test-ref ....`
We could also have this curl to some server with information on the
intermittent; so that we can keep track of these separately. It would also be
nice to have crowbot report them in chat (@jdm, is this possible?) and have
something comment on GH with a cross-reference.
This isn't too different from what we do already, we mostly just file or link to
an intermittent hit retry, and move on.
r? @larsbergstrom
cc @jack @edunham
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9572)
<!-- Reviewable:end -->
Give WindowProxy objects an innerObject hook.
This ensures that UncheckedUnwrap(obj, /* stopAtOuter = */ true) will indeed
stop at the WindowProxy ("outer window", in older SpiderMonkey jargon), which
is necessary to prevent raw Window ("inner window") objects becoming visible
to JavaScript code, or tripping assertions that we don't do that.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9584)
<!-- Reviewable:end -->
This ensures that UncheckedUnwrap(obj, /* stopAtOuter = */ true) will indeed
stop at the WindowProxy ("outer window", in older SpiderMonkey jargon), which
is necessary to prevent raw Window ("inner window") objects becoming visible
to JavaScript code, or tripping assertions that we don't do that.
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 -->
