This is unfortunate, but making that useful would require parameterizing
`SharedLayoutContext` and `LayoutContext` depending on the
`SelectorImpl` (which is a **huge** work right now).
Probably the easier way to do it, and probably the one that keeps the
layout code more legible, and since there won't be multiple
implementations at the same compilation unit, would be "defining" a
default implementation for layout via feature flags.
That should allow us to remove the components/style/servo.rs file.
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 -->
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 -->
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 -->
