compositor: When WebRender is in use, only composite on new WebRender frames.
Scheduling composition on scroll and so forth is unnecessary and can
cause us to miss frames if the code happens to start the composition
while the WebRender backend is still in the process of preparing the
frame. This is most easily seen when scrolling in full-screen mode in
release builds on Mac.
Closes#9879.
r? @glennw
cc @paulrouget
cc @tschneidereit
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10936)
<!-- Reviewable:end -->
frames.
Scheduling composition on scroll and so forth is unnecessary and can
cause us to miss frames if the code happens to start the composition
while the WebRender backend is still in the process of preparing the
frame. This is most easily seen when scrolling in full-screen mode in
release builds on Mac.
Closes#9879.
navigation.
Since WebRender uses the pipeline ID stored in the iframe element to
determine which pipeline to display, it had better be kept up to date!
Closes#9919.
* Sections like `[dependencies.foo]` can be entries in a `[dependencies]`
section with the `{key = value}` syntax.
* Per-target dependencies can be expressed with more general `cfg(…)`
conditions instead of exact target triples:
https://github.com/rust-lang/cargo/pull/2328
add pass-through from doc to http-loader for referrer_policy, ref_URL
add logic for setting referer header
add script pass-through for referrer
add unit tests for setting referer header
Implement scroll, scrollLeft, scrollTop and friends, addressing issue #9650
This is a work in progress to solve https://github.com/servo/servo/issues/9650. Thanks a lot for helping the review.
- [x] scroll
- [x] scrollTo
- [x] scrollBy
- [x] scrollTop (setter and getter)
- [x] scrollLeft (setter and getter)
The setters will be implemented in another PR after this is merged.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9968)
<!-- Reviewable:end -->
Add new compositor message to get scroll_offset;
Add new layout query for computed value of overflow-x/y;
Implement layer_id method for ThreadSafeLayoutNode;
Add new layout query for layer_id;
Implement script interface for getting scrollTop and scrollLeft, as well as relavant helper functions.
Added panic message to failures.
Added the panic message to failures. This is a step towards #10334, since it gives us access to the panic error message when we fire a `mozbrowsererror` event. The remaining steps are also to record the backtrace, and to report the failure in the event.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10587)
<!-- Reviewable:end -->
In rust-url 1.0 the `Url` struct is going to have private fields, and there
is no way to to create an aribitrary one without going through the parser.
The plugin never had a clear demonstrated performance benefit,
it was made mostly because it was possible and relatively easy at the time.
Without this `./mach run -b -- -M` would start fine but navigating to a site would fail with:
`thread 'ScriptThread PipelineId { namespace_id: PipelineNamespaceId(0), index: PipelineIndex(0) }' panicked at 'assertion failed: mozbrowser_enabled()', /Users/ulf/Documents/Code/servo/components/script/dom/htmliframeelement.rs:163`
The main issue was resources_dir_path. Every time it was called it would start from the executable's path and walk up the hierarchy to find a directory named "resources". The sandbox was granted permission to read from the found resources dir, but after the sandbox had been activated resources_dir_path would again start from the executable's path and try to find the resources dir. It would then fail with "Operation not permitted" when trying to canonicalize the path because it didn't have permissions to read metadata under ./target.
To fix this the resources dir path is now cached between resources_dir_path calls.
