When enabling lazy frame construction, whitespace only node might not have frame. So editor/libeditor/tests/test_bug1315065.html is failure because nsFrameSelection::MoveCaret returns error since focus node is whitespace only node that has no frame.
So if focus node is whitespace only, we should promote to parent to get primary frame then try again.
MozReview-Commit-ID: K83T2LP3Pc5
--HG--
extra : rebase_source : 707584424e83574dd3151e12a915473f676ce5a0
<!-- 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
- [x] These changes fix#18006 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- 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. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 5b4c9c7c770c676bd9eb2721fb23764e56c43dcc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : caeada20731ad0d447bc1c21f0173b417e660c67
For the Obama wikipedia page, this covers about 85% of the unmeasured
ComputedValues structs. The about:memory output looks like this:
> +---2,443,648 B (02.41%) -- computed-values
> | +--1,088,272 B (01.07%) -- dom
> | +----945,744 B (00.93%) -- non-dom
> | +----409,632 B (00.40%) -- visited
I'm not sure why some CVs are still being missed.
MozReview-Commit-ID: 1bYWwSi4ihn
--HG--
extra : rebase_source : 14e4bd36a54bbbd8fd265f559704bec5a5e3b154
This corrects a bug introduced in 265873cf1388.
MozReview-Commit-ID: LkZlTVAM17E
--HG--
extra : rebase_source : bf442e620abd6b47adee3d4c56e6f0c19964aea1
More progress on unifying how Gecko and Servo track stylist dirtiness.
Source-Repo: https://github.com/servo/servo
Source-Revision: e60266a72302a0ed332f1dd18d335b6092c47da4
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : fd8bbea82543a1a6a759806329e7ef2abe78bcc8
Fix the file access check by adding missing parentheses to isDirectory method call.
Don't run the cookies file check on Linux because the test profile is read accessible due to being in /tmp.
MozReview-Commit-ID: lps2hk8f5U
--HG--
extra : rebase_source : 5fba75d65081e56df5a0d171c41689c489a3aace
Currently, we listen to click events on the xbl binding; but actually we should
listen to click events on the input element itself, so that we get called when
the padding area is clicked.
MozReview-Commit-ID: 8NQKrxSXUyL
--HG--
extra : amend_source : 6106cd61c85a94b8272f2c8ff9abc68320946cbb
Fix the long-standing bug where items that are positioned and have
overflow:scroll or overflow:auto automatically create stacking
contexts. In order to do this we need to fix another bug where display
list sorting can put a Clip or ScrollFrame definition after the first
time it is used in a display list.
<!-- 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 #__ (github issue number if applicable).
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- 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. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 4725a05bfba0b588d19af8bc5cfe960bda1ea880
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 1c3dd60a7913ab76c637b8bd715ca2bf3d287243
There are two issues with this test:
(a) It fails to flush style when it intends to trigger the first transition.
Specifically, `getComputedStyle(div)` alone does not flush style. Instead we
need `getComputedStyle(div).transform`.
This patch replaces that line with a call to `div.getAnimations()` which
*does* flush style ensuring the first transition is triggered.
(b) It fails to ensure that the first transition has progressed past the first
frame on the main thread before triggering the second transition.
If the first transition is still on its first frame, the computed value of
'transform' will be 'matrix(1, 0, 0, 1, 0, 0)'. If we then update the
specified value of 'transform' to 'translateX(0px)', no transition will be
generated (although the first transition will be canceled) since there is no
change.
This patch fixes that by making the end point of the second transition NOT
match the start point of the first transition (and not be somewhere inside
the range of the first transition).
As an extra precautionary measure, to be sure that the animation has started
progressing on both the main thread and compositor, this patch alters the
initial wait condition for the first transition to also wait on the first
transition's ready promise.
MozReview-Commit-ID: E1OJuHBSMfr
--HG--
extra : rebase_source : aede0fa00f261e1c7d1be61857b6fd0537a0f7e7
The promise returned by a function created with DebuggerClient.requester was
resolved with the raw response, i.e. without any modifications that could
happen in the after callback.
MozReview-Commit-ID: Bd81eTsZ9YB
--HG--
extra : rebase_source : 304a93aa90f5100b60cd27dcb88d4b101a307661
extra : source : 00159b917049461606286cd2fa13e5699b56fd37
This patch has no direct relation with this bug. When tracing the code, I noticed
those local nsSVGLength2 variables can be declared as const reference.
MozReview-Commit-ID: 6gkdlpv8W7H
--HG--
extra : rebase_source : 0b875b0a375e9254eec3d1c569274fae8edfdcfe
There are two overloads of nsSVGLength2::GetAnimValue:
1. float nsSVGLength2::GetAnimValue(nsSVGElement*) const;
2. float nsSVGLength2::GetAnimValue(SVGSVGElement*) const;
In Bug 265894, I created SVGViewportElement as a base class of SVGSVGElement.
SVGSVGElement::GetViewBoxTransform was moved to SVGViewportElement in that
refactoring. The local variable 'ctx' in that function was changed from
SVGSVGElement to SVGViewportElement, which when passed to
nsSVGLength2::GetAnimValue caused us to switch from calling the overload that
takes a SVGSVGElement to the overload that takes a nsSVGElement, which is not
what we want.
This patch changes the argument type of the nsSVGLength2::GetAnimValue overload
that takes an SVGSVGElement to take an SVGViewportElement instead, which causes
the GetAnimValue(ctx) calls in SVGViewportElement::GetViewBoxTransform to call
the correct GetAnimValue overload again.
MozReview-Commit-ID: 2cmgIoltYfY
--HG--
extra : rebase_source : b45282cc492cf067ecc3935b03cde243a69ef2b5