CLOSED TREE
--HG--
extra : amend_source : 7618f27e1cf71347f12384935374d303d5c1ab23
extra : histedit_source : 1143d226673ace563bb5d9ff3c420ded33439791%2C9746a30097304bd2214a0072773dc00c767d31cd
This was a test case for bug 1379203 (Google Inbox issue), but to pass this test
also needs the fix in this series to cancel animations when changing
animation-name to 'none' in the specified CSS rule.
Actually the fix in this series also fixes the Google Inbox issue so that this
test can pass without the fix for the Google Inbox issue. But even so without
the fix for bug 1379203, the style data for the first div element in this test
is cached and the second div element uses the cached data.
MozReview-Commit-ID: GfKSDfTZef4
--HG--
extra : rebase_source : caad72ed69e4ebeec8b8cad25949ea69e3bb652e
In the case where values in CSS rules changed directly by CSSOM, the old
value in the CSS rule block is immediately replaced by the new one. So if
the element, which is applied to the CSS rule, has running animations, the
new value is used during cascading process in animation-only restyle. Thus
in a subsequent normal restyle, we can't tell whether the value in the CSS
rule has changed or not. As a result, transitions may not be triggered
(bug 1393323) and CSS animations may not be cancelled if the updated
animation-name is 'none' (this bug).
For the latter case of CSS animations where animation-name has been updated to
'none', this patch introduces a workaround whereby we trigger an update of
running animations whenever the traversal is triggered by changes to CSS rules
and we have existing CSS animations.
change-animation-name-to-none-in-rule.html fails without servo #18214, succeeds
with this patch. Other two tests succeed regardless of the PR.
MozReview-Commit-ID: BrZgTNk9w41
--HG--
extra : rebase_source : 7a55f54a0f94c8db02639f9d8c89f785b3a17a1b
Since these tests harnesses are already disabling Safe Browsing and tracking
protection, they should also disable the other two features that cause
lists to be downloaded from the Mozilla shavar server.
MozReview-Commit-ID: 2158qRU4XZx
--HG--
extra : rebase_source : 287bfb7580538cca7f58ab035b7141166346c318
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
Manish Goregaokar
J. Ryan Stinnett
Sebastian Hengst
Chung-Sheng Fu
Ryan VanderMeulen
Gregory Szorc
Bas Schouten
Nazım Can Altınova
Hiroyuki Ikezoe
Brad Werth
Francois Marier
Kris Maglione
Wes Kocher
Brian Birtles
Ting-Yu Chou
cku
Jeremy Chen
Nicholas Nethercote
Eric Rahm
Alexis Beingessner
Kartikaya Gupta
angelsl
Emilio Cobos Álvarez
Makoto Kato
Bobby Holley
Mantaroh Yoshinaga
Honza Bambas
Masatoshi Kimura