Fix the "get the parent" loop when dispatching event (fixes#6733)
The DOM specification says:
> A document's get the parent algorithm, given an event, returns null
> if event's type attribute value is "load" or document does not have
> a browsing context, and the document's associated Window object
> otherwise.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9734)
<!-- Reviewable:end -->
The DOM specification says:
A document's get the parent algorithm, given an event, returns null
if event's type attribute value is "load" or document does not have
a browsing context, and the document's associated Window object
otherwise.
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 -->
