For example, in dom/base/nsGkAtomList.h, we currently have:
GK_ATOM(mouseWheel, "mouseWheel") // For discrete wheel events (e.g. not OSX magic mouse)
but if we change to
GK_ATOM(mouseWheel,
"mouseWheel") // For discrete wheel events (e.g. not OSX magic mouse)
The parser didn't handle the declaration
Introduce nsStaticAtom.
It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)
<!-- Please describe your changes on the following line: -->
---
<!-- 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
- [ ] These changes fix https://bugzilla.mozilla.org/show_bug.cgi?id=1411893
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because tested on the Gecko side.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- 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/19035)
<!-- Reviewable:end -->
It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)
In Gecko, we handle XBL rules like author rules everywhere, except that
XBL rules are added and sorted in an independent step, behave as if it
has a separate level.
It is not clear to me why Stylo chose to add a separate level for XBL
rules, but it doesn't seem that there is anything special to do with
XBL rules.
This bug happens because we don't handle XBL important rules which are
handled as part of author rules in Gecko due to lack of the additional
level there. We should just follow what Gecko does here and handle them
all the same.
This avoids threading the quirks mode and nth-index cache around, and prevents
having to thread even more arguments down for the querySelector stuff (at least
VisitedHandlingMode and the style scope).
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Remove unnecessary Result::ok calls
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they are code cleanup only
<!-- 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/18972)
<!-- Reviewable:end -->
Use env::var_os to read paths from the environment
This avoids unnecessary UTF-8 validation on OsStrings that we just pass
back to the OS.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they are code cleanup only
<!-- 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/18971)
<!-- Reviewable:end -->
stylo: Avoid using InterpolateMatrix as a fallback for matched transform function pair
In the current implementation, if there is any interpolation error in a matched
transform function pair, we fall-back to use InterpolateMatrix unconditionally.
However, the error could be caused by:
1. mismatched transform function pair
2. matched transform function pair within at least one undecomposable matrix.
Using InterpolateMatrix for case 1 makes sense, however, using InterpolateMatrix
for case 2 does not. According to the spec, we should just report error for
case 2, and let the caller do the fallback procedure. Using InterpolateMatrix
for case 2 will go through more unnecessary code path, and produce more memory
usage and calculation cost, which should be avoidable.
In this patch, we add an extra pass to check if a transform function pair have
matched operations in advance. With this information, we can easily tell whether
the interpolation error in a equal-length transform function pair is caused by
case 1 or case 2. So, we can avoid the unnecessary cost.
---
<!-- 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 [Bug 1399049](https://bugzilla.mozilla.org/show_bug.cgi?id=1399049)
- [X] These changes do not require tests because the change is for some performance gain, and we have tests to ensure that we won't regress the existing behavior already.
<!-- 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/18966)
<!-- Reviewable:end -->
