Completed implementation of devtools' `getLayout`.
Rebase of #7267. Fixes#3598.
This avoids all of the sketchy issues of trying to read the style data for margins from the script thread. I replaced it with a layout query that fetches the margin style properties for a given element.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9661)
<!-- Reviewable:end -->
Dirty elements whose selectors are affected by sibling changes
This fixes incremental layout of nodes that match pseudo-class selectors such as :first-child, :nth-child, :last-child, :first-of-type, etc. Fixes#8191 and other intermittent layout bugs.
This code is based on the following flags from Gecko:
https://hg.mozilla.org/mozilla-central/file/e1cf617a1f28/dom/base/nsINode.h#l134
Depends on servo/rust-selectors#71. r? @SimonSapin
There are a couple of TODO items in this commit, but I'd appreciate feedback on the general approach before I finish it up. (Also, if someone who knows more than I do could give some advice about atomic orderings...)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9722)
<!-- Reviewable:end -->
Stop returning an Option from Window::browsing_context.
A Window always has a WindowProxy; the only reason it's wrapped in a nullable
field is the order in which those objects are created.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9729)
<!-- Reviewable:end -->
According to JSProxy.h, without this the default implementation calls
ownPropertyKeys and filters out the unenumerable properties. We know when such
things exist so we don't need to do that.
Implement XHR::SetRequestHeader Step 3
Closes#9548.
Alternative implementation of #9595.
cc @timvandermeij
I'm not sure if a utility method on `ByteString` is the best place for this functionality, maybe a free function in XHR module would be more suitable.
Also where would be the correct place to add a test for this functionality (if required)?
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9598)
<!-- Reviewable:end -->
Timers clean up
This PR splits the `ActiveTimers` abstraction into
- `OneshotTimers` for scheduling "arbitrary" oneshot timers, such as XHR timeouts, and
- `JsTimers`, based on `OneshotTimers`, for scheduling JS timers (`setTimeout`/`setInterval`).
The result is mich cleaner and the timer initialization steps now closely resemble the specification.
**Notes**
- The second and third commit are strictly renames and code rearrangements.
- I'm not particularily happy with the `OneshotTimerCallback` enum and its circular dependency with `XHRTimeoutCallback`, but I couldn't come up with anything better.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8603)
<!-- Reviewable:end -->
The code was split into the following two abstractions.
- OneshotTimers can be used to schedule arbitrary oneshot timers, such
as XHR-Timeouts.
- JsTimers (`setTimeout` and `setInterval`) which use OneshotTimers to
schedule individual callbacks.
With this change the implementation (of JsTimers in particular) is in
much closer alignment with the specification.
