After this patch, when the page calls `requestAnimationFrame()` too many
times in the row without actually mutating the DOM, further calls to
`rAF` will actually perform the moral equivalent of `setTimeout(16)`.
This saves a lot of CPU time compared to actually waiting for the
vertical blanking interval, because waiting for that requires us to draw
the page.
Reduces CPU usage drastically on nytimes.com, which has a perpetual
`requestAnimationFrame()` loop that checks whether ads are in view.
Replace return_address usage for rooting with stack guards and convenience macros.
The existing `Rooted` and `RootedVec` users were migrated the the following two macros:
```rust
let x = Rooted::new(cx, value);
// Was changed to:
rooted!(in(cx) let x = value);
// Which expands to:
let mut __root = Rooted::new_unrooted(value);
let x = RootedGuard::new(cx, &mut __root);
```
```rust
let mut v = RootedVec::new();
v.extend(iterator);
// Was changed to:
rooted_vec!(let v <- iterator);
// Which expands to:
let mut __root = RootableVec::new();
let v = RootedVec::new(&mut __root, iterator);
```
The `rooted!` macro depends on servo/rust-mozjs#272.
These APIs based on two types, a container to be rooted and a rooting guard, allow implementing both `Rooted`-style rooting and `Traceable`-based rooting in stable Rust, without abusing `return_address`.
Such macros may have been tried before, but in 1.9 their hygiene is broken, they work only since 1.10.
Sadly, `Rooted` is a FFI type and completely exposed, so I cannot prevent anyone from creating their own, although all fields but the value get overwritten by `RootedGuard::new` anyway.
`RootableVec` OTOH is *guaranteed* to be empty when not rooted, which makes it harmless AFAICT.
By fixing rust-lang/rust#34227, this PR enables Servo to build with `-Zorbit`.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fixrust-lang/rust#34227
- [x] These changes do not require tests because they are not functional changes
<!-- 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/11872)
<!-- Reviewable:end -->
Implement non-visible pipeline and iframe visibility methods
This addresses #9566 and a good part of #9751, specifically:
* Pipeline has a notion of visibility
* IFrame setVisible/getVisible interface with IFrame's pipeline visibility
* IFrame mozbrowservisibilitychange responds to changes in visibility
* Pipeline visibility is used to limit animations (requestAnimationFrame does not tick animations when hidden) and to increase timer intervals (currently set to a minimum of 1 second while hidden)
Absent for now are any changes to the Document API and general implementation of the Page Visibility API, since the more interesting parts require knowledge of whether the user agent is minimized, OS screen locked, etc.
cc @paulrouget @jdm
<!-- 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/10225)
<!-- Reviewable:end -->
It's not clear to me if this is something we should expect to happen, but it
does indeed happen, so we should disable the assertion while we investigate.
Fixes#9984.
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.
Functions returning `Root<T>` are prefixed by "root_" and the ones returning
`*const T` by "native_".
Functions taking `*mut JSObject` are now suffixed by "_from_object" and the ones
taking `&T` by "_from_reflector".
Fixed panic in ActiveTimers.set_timeout_or_interval.
`ActiveTimers.set_timeout_or_interval` asserts that the pipeline is not currently frozen. Apparently that is too strict. When pending network requests complete after a pipeline is frozen, scripts may be executed and a timer scheduled.
With these changes scheduling a timer while the pipeline is frozen behaves as if the timer was scheduled at the time the pipeline was frozen.
To reproduce the panic
1. `./mach run -r http://google.com`,
2. immediately click on any link and
3. wait for the panic.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8175)
<!-- Reviewable:end -->
