Implement discarding Document objects to reclaim space.
<!-- Please describe your changes on the following line: -->
This PR implements document discarding. Active documents are kept alive strongly, but inactive documents are only kept alive weakly. When a document is GCd, it is marked as discarded, and if it is every reactivated, a reload of the URL is triggered.
Note that this PR is pretty aggressive about discarding, and can any inactive document (other than those being kept alive by other same-origin pipelines). We might want to damp it down a bit.
Also note that this interacts with browser.html in that the reloading triggered by reactivating a document triggers mozbrowser events.
To test this, I added a `-Zdiscard-inactive-documents` debug flag, which discards all inactive documents, even ones which are reachable through other same-origin pipelines.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#14262.
- [X] These changes do not require tests because we should be able to use the existing tests with `-Zdiscard-inactive-documents`.
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14312)
<!-- Reviewable:end -->
Avoid restyling elements that aren't in a document
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#14480
- [X] There are tests for these changes
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14845)
<!-- Reviewable:end -->
Properly dispatch keypress event
<!-- Please describe your changes on the following line: -->
This was an attempt to fix#14659. It turned out that the problem wasn't what I thought it was. So, I didn't fix that. On the brighter side, this fixes two related issues.
- Previously, we were unable to launch `keypress` events from `input` and `textarea` elements, because [we'd been cancelling](1327ebd52f/components/script/dom/htmlinputelement.rs (L1120-L1124)) the key events, so that they don't trigger window navigation - #8400). I've introduced an enum to represent an additional state to an event's cancellation.
- [According to the spec](https://w3c.github.io/uievents/#keypress-event-order), `keypress` (if available) should be dispatched immediately after `keydown`, and it should be followed by `input`. Canceling `keypress` should also cancel `input`. But, we'd been dispatching `input` before `keypress`. We now dispatch `input` once the `keypress` event is on the respective elements.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [x] These changes do not require tests because it's a refactor?
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
r? @jdm or anyone interested
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14738)
<!-- Reviewable:end -->
style: Simplify Debug impl for PropertyDeclaration reusing to_css.
These two functions appear in the data from bug 1328497, and the second part of one is identical to the other.
I think the way to fix this is another one (either using static arrays to get
the interesting data, or making rust generate the equivalent code).
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14844)
<!-- Reviewable:end -->
These two functions appear in the data from bug 1328497.
I think the way to fix this is another one (either using static arrays to get
the interesting data, or making rust generate the equivalent code).
Reimplement AtomicRefCell with pure atomics
While reviewing @bzbarsky's patches in [1], I started typing out some lore about how mutable AtomicRefCell borrows are actually cheaper than immutable ones, so we should prefer them where possible. But then I decided that this was a really dumb state of affairs and that we should just fix AtomicRefCell instead, and implement a proper AtomicRef{,Mut}::map while we were at it. So here we are.
This PR adds a from-scratch implementation of AtomicRefCell that aims to be 100% sound, even in unrealistic overflow scenarios. We should probably get this on crates.io eventually, but I want to land it landed in-tree first.
With this implementation, each operation (borrow or release) is one atomic instruction, and all borrow/release pairs (mutable or immutable) take 12 ns on my machine, which is what I'd expect. This is a 50% improvement over the previous implementation in the immutable case.
There may be some places where we could get away with Ordering::Release instead of Ordering::AcqRel, but it didn't seem worth it to try to reason it out.
r? @Manishearth
CC @emilio @SimonSapin @heycam @upsuper
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1298588
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14828)
<!-- Reviewable:end -->
