The FrameLoaderOwner interface has been implemented in WebIDL for several
years now, so these QIs are simply unnecessary overhead.
MozReview-Commit-ID: LAzvfm5Qhy0
--HG--
extra : rebase_source : 2495c07df21c474f5fabc257ff4db43b0d8047e4
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
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 straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
The bug is caused by the first call to ResizeReflow in
nsDocumentViewer::GetContentSizeInternal, which reflows the content with
unlimited height. ResizeReflow calls DidDoReflow, which calls a
callback installed by nsHTMLScrollFrame that clamps the scroll port setting
the scroll top to 0 and losing the original scroll top. When the content
is reflowed again to the maximum height, the scroll top stays at 0.
MozReview-Commit-ID: 3VkgWLqSTDP
--HG--
extra : rebase_source : 68c65746e014f0702de82ea576897592b07f81cb
There's only one case of sync frame construction from ContentRemoved now, and
it's not on the element being removed, but on the whitespace siblings if needed,
and _only_ when they don't support lazy frame construction.
Basically, this switches all the RecreateFramesForContent calls to use
`aAsyncInsert` (which I changed to an enum class for readability), except when
we're already reframing.
Also, it switches ReframeTextIfNeeded to opt-in into lazy frame construction,
since it's used only when aFlags == CONTENT_REMOVED.
This allows to simplify the DestroyFramesFor API (which I'm happy to rename to
something more meaningful, since now it's something like
DestroyFramesForAndRecreateThemAsync), and do some other consistency cleanups.
A bunch of the ContentRemoved callsites were pretty random at passing
aAsyncInsert, and that was some kind of a mess. This patch ensures consistency,
and makes it impossible to do O(n^2) work when removing DOM nodes, which is
nice.
The underlying reason for this is explained in the description of bug 1377848,
and basically allows us to remove a bunch of Servo hacks on the longer term (a
few of them are going away already, yay!).
MozReview-Commit-ID: 2DrUTxGV8RX
--HG--
extra : rebase_source : f428d839a5482477dea22c0fea600d54f3e8799c
The login reputation checks depend on a server lookup and therefore would
render non-deterministic the performance and correctness of tests.
MozReview-Commit-ID: Bil0rSZsGPT
--HG--
extra : rebase_source : ae06a028c71eee323307ecd4e62bbf1e8a14fe13
The login reputation checks depend on a server lookup and therefore would
render non-deterministic the performance and correctness of tests.
MozReview-Commit-ID: Bil0rSZsGPT
--HG--
extra : rebase_source : c9a641e4bf49c48bf864ed546bf2ae6eb51c27e4
This shouldn't be at module level.
This isn't technically needed for this series. I caught it during
an earlier attempt at teasing out all Python import dependencies
to run `mach`. Why let a good patch go to waste.
MozReview-Commit-ID: FwwdZqcKtpq
--HG--
extra : rebase_source : a8ce2cf452dc8c03371dc384ea4f1be9195b5d30
Sometimes, we may get a 2d transform matrix like this:
matrix(0, 1, -1, 0.33, 0, 0)
The reason is we might have "rotate(90deg)" in the test case, so the 1st or
the 4th element could be 0.0, and we shouldn't assume they are 1.0 while
converting matrix2d into matrix3d, or we will get a weird result, like this:
matrix3d(1, 1, 0, 0,
-1, 0.33, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1)
m11 shouldn't be "1" here.
Add a "defined()" function to return the first defined object as the
matrix element because we should be testing the defined-ness, instead of
truthiness.
MozReview-Commit-ID: HSTt2PR02AU
--HG--
extra : rebase_source : 417438239635f9bbf0eb4818b39c611ab90b9a10
In particular, this avoids the stupid calls in display: none roots.
The cache stuff should be unnecessary, but there's still some fishy stuff going
on.
MozReview-Commit-ID: LgnW0k1gmsN
--HG--
extra : rebase_source : b07e1f2533e4a2fc1610f35351fc2964f37e82e2
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the caller will pass along space for the
struct return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: JHDp0XAmQCG
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
