There are three test cases which are actually wrong, for example:
* offsetContainer=use&mask=userSpace-at100
This test case is actually wrong one. All the content of <use> element should
be masked out by the selected mask. We should use <mask id="userSpace-atZero">
instead.
MozReview-Commit-ID: B3D2gTWmwXC
--HG--
extra : source : fcb3c9a6426e9a54a28abd5acf4448bbfac5cf0c
extra : histedit_source : 8d6c685c4d051f0e20bc286d2ab829e47d22efef
For nsSVGUtils::FrameSpaceInCSSPxToUserSpace:
If we give a nsSVGUseFrame to this function, it will return <use>'s x/y as
translation vector, which is not necessary. A point (a, b) in frame's
coordinate space should keep (a, b) in <use>'s coordinate space with no change.
Since we remove extra translation in nsSVGUtils::FrameSpaceInCSSPxToUserSpace,
aslo update nsSVGUtils::GetBBox accordingly.
MozReview-Commit-ID: BMjSonjoWd2
--HG--
extra : source : e32814fc5ab6fdb9e723b8109aa8f398b1c883f6
extra : histedit_source : 564968d47a3d95fde8e5b83c55148b63c1feb085
There are three test cases which are actually wrong, for example:
* offsetContainer=use&mask=userSpace-at100
This test case is actually wrong one. All the content of <use> element should
be masked out by the selected mask. We should use <mask id="userSpace-atZero">
instead.
MozReview-Commit-ID: B3D2gTWmwXC
--HG--
extra : rebase_source : 09390a59d6bcd187e0e8b99ca6a78da84af49805
For nsSVGUtils::FrameSpaceInCSSPxToUserSpace:
If we give a nsSVGUseFrame to this function, it will return <use>'s x/y as
translation vector, which is not necessary. A point (a, b) in frame's
coordinate space should keep (a, b) in <use>'s coordinate space with no change.
Since we remove extra translation in nsSVGUtils::FrameSpaceInCSSPxToUserSpace,
aslo update nsSVGUtils::GetBBox accordingly.
MozReview-Commit-ID: BMjSonjoWd2
--HG--
extra : rebase_source : da629ba4464534a89718db1cd5b9705261ae4a4d
Two main notes:
* The nsStringBuffer bit goes untested, since it's only used on windows and
there's no way I can test it, please review with care.
* I haven't implemented yet the "enumerated" media queries. I'd want to do it
as a follow-up, because I'm running out of time, and it requires some
investigation.
MozReview-Commit-ID: 1pBbzyIViPk
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
The getter function may create an nsCSSValue with allocated stuff, and we don't
want to leak it.
MozReview-Commit-ID: DYkUD8CW88E
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
The setup is quite different to Servo-land, so add a comment about the different
setup.
Also, check viewport rules when flushing stylesheets. I believe that the
previous behavior is plain wrong, though I haven't taken the time to come up
with a test case.
In any case, it doesn't hurt any of both back-ends.
MozReview-Commit-ID: 46gtTkesOsr
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
We aren't likely to implement predictive size decoding for XUL images. So instead do some sync decoding when we Draw them at their specified size. This will avoid a paint where we don't draw the image, or draw it at the wrong size, followed later by the correctly sized image.
Now we skip nsAnimationManager::UpdateAnimations() and
EffectCompositor::UpdateEffectProperties() in case of
GetStyleContextForElementWithoutAnimation().
MozReview-Commit-ID: 4rF6n3XtMQq
--HG--
extra : rebase_source : b71e6a080df9ad730a4ee0b67d217d7f74df7de8
This has the same functionality of ResolveStyleWithoutAnimation() but for pseudo
element instead.
MozReview-Commit-ID: I34lrfqdtuP
--HG--
extra : rebase_source : 5467923c4a4cb06e8999a1116cc2da9b2ed89c5e
Unlike the other one this function does not need an old nsStyleContext.
This function just resolves style without all animation data in the first place.
The existing ResolveStyleWithoutAnimation is renamed to
ResolveStyleByRemovingAnimation.
MozReview-Commit-ID: 1RmCQNw0MmW
--HG--
extra : rebase_source : eaf55ecac77f6bb803b1f9508444bf34106d6da3
We need another variant of GetStyleContextForElement() that does not consider
animation rules at all to get the base styles of the target element (i.e.
styles without animations).
In subsequent patches we also skip nsAnimationManager::UpdateAnimations() and
EffectCompositor::UpdateEffectProperties() to avoid (indirect) recursive calls
for resolving style of the same element.
MozReview-Commit-ID: G5olgXIMtvY
--HG--
extra : rebase_source : 1d08e649a4355262e2d83102c7b2de22cd7a67a1
Since we use the presence of a change hint to determine whether we should
recreate a style context, we can't just strip them out on CalcStyleDifference.
MozReview-Commit-ID: GLhbTc2W3d7
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
cku
Iris Hsiao
Wes Kocher
Daniel Holbert
Bill McCloskey
Emilio Cobos Álvarez
Florian Quèze
Cameron McCormack
Timothy Nikkel
Phil Ringnalda
Carsten "Tomcat" Book
Hiroyuki Ikezoe
Xidorn Quan
Jesse Ruderman
Mats Palmgren
Jonathan Kew