If the buffer status was changed, we should do the ValidateBufferFetching() again.
MozReview-Commit-ID: 7czQFT3qauE
--HG--
extra : rebase_source : ee2635289d0d3e7c115b2a9d9f52c3ae876830d5
This will enable lazy loading symbols for a grip if needed.
This patch introduce a new SymbolIteratorActor, which is similar
to PropertyIteratorActor but with a data structure that better
fits symbols, and how we already handle them, i.e. an `ownSymbols`
array property (and not an `ownProperties` object like PropertyIteratorActor).
We take this as an opportunity to add a test for enumSymbols, but also
for enumProperties that did not have server unit tests (it is only tested
in the frontend with the variable view, which might be deprecated at some
point).
MozReview-Commit-ID: IEIKA8zwH90
--HG--
extra : rebase_source : 377526321e04e28ffc58ed7af7f4325b6e1ee66d
Version 4 of the Google Safe Browsing server will return a 404 if any of the
application reputation lists are requested on Android. As a result, we should
avoid these threat types from being sent along with ANDROID_PLATFORM.
MozReview-Commit-ID: 6TUBVxe455y
--HG--
extra : rebase_source : dee095c008f4d328f359c66d20f0cc2dfcd109f3
extra : source : 5d6338807c6b21b7672236cac01b13bd75155225
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
In Stylo, if there exists one or more <script> elements in the document, frame
construction might happen earlier than the UpdateCharSet(), which leads to an
incorrect style data for the frames. So, we force a restyle in this situation,
to make the style data of all the descendants up-to-date.
MozReview-Commit-ID: BwCwp6Ndvmc
--HG--
extra : rebase_source : 0cfadd3d57b4f8482251f8006a51740873cda3b9
In Stylo, we read font related user prefs to set the default font size only
if we set 'font-size' property. However, users are allowed to set their
preferred minimum font size through the user prefs, even without using
'font-size' property.
Gecko used to do this in nsRuleNode::SetDefaultOnRoot, which calles the
default constructor of nsStyleFont and does the minimum font size applying
right after. Moving the minimum font size applying into the default
constructor of nsStyleFont shoud be no harm to Gecko, but makes Stylo
share the same code path and behave the same.
MozReview-Commit-ID: BDcJX92o0uR
--HG--
extra : rebase_source : 88d9c73d0eb793ffe8a5dc424361f21f6acd078b
This is meant as a stop-gap measure to stop the obviously bad thing from happening.
MozReview-Commit-ID: Gqvc32K04xD
--HG--
extra : rebase_source : 04f1b5cb7ead6b7949b8433b3fc75c0d67283315
