Use macro for boilerplate code in webdriver `handle_*`
Add a macro for the boilerplate code that appears in most of Handler's methods handling a `WebDriverScriptCommand`.
There are at least three steps that appear in most `Hande::handle_*` methods that handle a `WebDriverScriptCommand`, so I created a simple macro that generates the equivalent code.
There are pros and cons to using a macro like this. It does reduce boilerplate code, but it also can make the code harder to read. Please let me know if you have any comments!
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9747)
<!-- Reviewable:end -->
PR #9208 added the ability to perform layout before an `<img>` resource is
fully loaded. However, when we are rendering to an image file for testing
purposes, we need to block until the image content is fully loaded (until
issue #9441 is fixed).
Fixes#9550.
Validate MIME pattern checking
The MIME detector for a HTML file contains an additional byte in the mask. While it doesn't hurt, it is not used in the byte matching code (since it is zipped with the `pattern` iterator).
I'm not clear how to test this within the `servo` code. The fix doesn't change any externally visible behavior. A test to validate the `ByteMatcher` structures would require the private ByteMatcher structures to be visible to the test. I could use a sub-module, as described at https://doc.rust-lang.org/book/testing.html#the-tests-module but this pattern doesn't appear anywhere else in the `servo` code.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9631)
<!-- Reviewable:end -->
compositing: Stop compositing unnecessarily after each animation frame.
Instead, schedule a delayed composite after each frame of an animation.
The previous code would cause jank, because the following sequence
frequently occurred:
1. The page uses `requestAnimationFrame()` to request a frame.
2. The compositor receives the message, schedules a composite,
dispatches the rAF message to the script thread, composites, and goes to
sleep waiting for vblank (frame 1).
3. The script makes a change and sends it through the pipeline.
Eventually it gets painted and is sent to the compositor, but the
compositor is sleeping.
4. The compositor wakes up, sees the new painted content, page flips,
and goes to sleep (frame 2). Repeat from step 1.
The problem is that we have two composition frames, not just one. This
halves Web apps' framerate!
This commit fixes the problem by scheduling the composite in step 2 to
12 ms in the future. We already have this delayed-composition
functionality in the form of the scrolling timer, which I repurposed and
renamed to the "delayed composition timer" for this task. This change
gives the page 12 ms to prepare the frame, which seems to usually be
enough, especially with WebRender.
Note that simply removing the scheduled composite after rAF is not the
correct solution. If this is done, then pages that call rAF and don't
modify the page won't receive future rAFs, since the compositor will be
sleeping and won't be notified of vblank.
Fixes a bunch of jank in browser.html. The remaining jank seems to be a
problem with browser.html itself.
r? @glennw
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9663)
<!-- Reviewable:end -->
Instead, schedule a delayed composite after each frame of an animation.
The previous code would cause jank, because the following sequence
frequently occurred:
1. The page uses `requestAnimationFrame()` to request a frame.
2. The compositor receives the message, schedules a composite,
dispatches the rAF message to the script thread, composites, and goes to
sleep waiting for vblank (frame 1).
3. The script makes a change and sends it through the pipeline.
Eventually it gets painted and is sent to the compositor, but the
compositor is sleeping.
4. The compositor wakes up, sees the new painted content, page flips,
and goes to sleep (frame 2). Repeat from step 1.
The problem is that we have two composition frames, not just one. This
halves Web apps' framerate!
This commit fixes the problem by scheduling the composite in step 2 to
12 ms in the future. We already have this delayed-composition
functionality in the form of the scrolling timer, which I repurposed and
renamed to the "delayed composition timer" for this task. This change
gives the page 12 ms to prepare the frame, which seems to usually be
enough, especially with WebRender.
Note that simply removing the scheduled composite after rAF is not the
correct solution. If this is done, then pages that call rAF and don't
modify the page won't receive future rAFs, since the compositor will be
sleeping and won't be notified of vblank.
Fixes a bunch of jank in browser.html. The remaining jank seems to be a
problem with browser.html itself.
Remove parallel display list construction
Parallel display list construction hasn't been shown to give any
performance gains. It is also incompatible with the current flat display
list implementation. Once flat display lists have landed, we can explore
possible benefits of parallel construction once again.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9706)
<!-- Reviewable:end -->
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.
