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).
Track stylesheet load's document instead of using element's current document
For cases where a stylesheet load finishes in a different document than it started, we need to be more careful about which document we report the completion to. In this case we actually have separate requests for each document involved, but they previously used the same element to determine which document to interact with.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#14641
- [X] There are tests for these changes OR
<!-- 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/14841)
<!-- Reviewable:end -->
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 -->
