Currently the way we set the NS_FRAME_MAY_BE_TRANSFORMED frame bit for transform
animations fails to take into account the primary/style frame distinction for
display:table content.
This patch moves setting that bit for animations to the point where we already
have a handle on the appropriate EffectSet and already detect the primary/style
frame distinction.
This should be equivalent because:
a) Although it is inside a branch that is only run when |mContent| is set,
nsLayoutUtils::HasAnimationOfPropertySet will return false if the passed-in
frame does not have associated content (see
EffectCompositor::GetAnimationElementAndPseudoForFrame).
b) EffectSet::MayHaveTransformAnimation() should be set if we have any
transform animations in the EffectSet so this should be equivalent to
querying nsLayoutUtils::HasAnimationOfPropertySet.
The only other consideration is that this code is only executed when aPrevInFlow
is nullptr. As a result, this patch also updates the branch where aPrevInFlow is
set to copy the NS_FRAME_MAY_BE_TRANSFORMED bit in that case too.
Differential Revision: https://phabricator.services.mozilla.com/D23636
--HG--
extra : moz-landing-system : lando
For most of the functions we call on this frame there will be no difference in
result since the transform styles are inherited from the style frame to the
primary frame. However, for Combines3DTransformWithAncestors() at least, which
calls IsCSSTransformed(), the result will differ.
Differential Revision: https://phabricator.services.mozilla.com/D23283
--HG--
extra : moz-landing-system : lando
There are many bugs regarding our use of EffectSet::GetEffectSet(nsIFrame*)
because the intention of the caller is not clear. If it is called for the
primary frame of display:table content do we expect it to get the EffectSet
associated with the style frame or not? Generally it depends on if we are
looking for transform animations or not.
Rather than inspecting each call site and making it choose the appropriate frame
to use, this patch introduces a new method to EffectSet to get the appropriate
EffectSet based on the properties the caller is interested in.
This patch also uses this function in FindAnimationsForCompositor which in turns
fixes the glitching observed on Tumblr that arose since a number of places in
our display list code were passing the style frame to
EffectCompositor::HasAnimationsForCompositor.
Over the remainder of this patch series we will convert more callers of
EffectSet::GetEffectSet(nsIFrame*) to this new method before renaming
EffectSet::GetEffectSet to GetEffectSetForStyleFrame to make clear how the
method is intended to work.
Differential Revision: https://phabricator.services.mozilla.com/D23282
--HG--
extra : moz-landing-system : lando
It took me a long time to understand why
KeyframeEffect::HasEffectiveAnimationOfPropertySet behaved so differently to
KeyframeEffect::HasAnimationOfPropertySet. This patch attempts to clarify that
while making KeyframeEffect::HasEffectiveAnimationOnPropertySet a little more
generally useful. This will allow us to tidy up the various animation checks in
nsLayoutUtils later in this patch series.
Ultimately, however, we should make this check part of the regular compositor
animation vetting machinery in bug 1534884. That should remove a number of
inconsistencies such that we don't need the extended comments added in this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D23281
--HG--
extra : moz-landing-system : lando
The trouble with utility functions that take an nsIFrame is it's not clear what
the caller's intention is. For example, with
nsLayoutUtils::HasCurrentTransition, is the caller asking for transitions on
that frame? Or animations on _both_ that frame and its corresponding
style/primary frame?
Probably the caller hasn't even thought about it and there are likely to be bugs
when display:table content is encountered.
Where practical it's much better to take an element/pseudo pair since it's clear
that the caller is concerned with all animations (or transitions in this case)
on the element regardless of how it is represented in the frame tree.
This patch updates nsLayoutUtils::HasCurrentTransition to take an element/pseudo
pair and moves it to mozilla::AnimationUtils at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D23280
--HG--
extra : moz-landing-system : lando
I was unable to create a failing reftest for this since this method is not
used when determining whether or not to create a stacking context.
However, I verified that for content with animated transforms and
will-change:transform on display:table content this change does cause us to
return true from the will-change check in this method when previously it would
not.
Differential Revision: https://phabricator.services.mozilla.com/D23279
--HG--
extra : moz-landing-system : lando
We test the transform-style of a frame in places like
KeyframeEffect::CanAnimateTransformOnCompositor but this will likely not work as
expected for display:table content since the transform-style will not be
inherited to the primary frame (and later in this patch series we will ensure
that we are dealing with the primary frame in
KeyframeEffect::CanAnimateTransformOnCompositor).
The individual transform properties are new but they should also be inherited so
that all the appropriate tests for "is this frame transformed?" produce the
correct result when these properties are applied.
Differential Revision: https://phabricator.services.mozilla.com/D23278
--HG--
extra : moz-landing-system : lando
In GLES 3 GLSL, the default precision for ints is highp (32 bit) in
vertex shaders, but only mediump (16 bit) in fragment shaders.
To render linear and radial gradients the fragment shader must fetch
the gradient stops from the gpu cache, using an address variable. This
variable is a 16 bit int, so if the stops data is located at
too high an address (row 32 or greater) then this value will have
overflown and we fetch from the wrong location. This was resulting in
garbage being drawn instead of the correct gradients.
To fix this, any address used in a fragment shader must be marked as
highp. This includes the varying input which supplies the address, and
the arguments to any functions used for the fetch.
Differential Revision: https://phabricator.services.mozilla.com/D23669
--HG--
extra : moz-landing-system : lando
This makes it possible to copy paste the number of times the message is repeated
Differential Revision: https://phabricator.services.mozilla.com/D23667
--HG--
extra : moz-landing-system : lando
This prop will add a classname in the NotificationBox element, that we then style to make the text wrap
Differential Revision: https://phabricator.services.mozilla.com/D23455
--HG--
extra : moz-landing-system : lando
A patch of mine starts calling nsLookAndFeel from xpcshell tests, which makes
gtk crash eventually.
Differential Revision: https://phabricator.services.mozilla.com/D23759
--HG--
extra : moz-landing-system : lando
ffxbld
Ionut Goldan
Brian Birtles
tanhengyeow
Marian Raiciof
Brindusan Cristian
ffxbld
Oana Pop Rus
Matthew Noorenberghe
André Bargull
Noemi Erli
Jamie Nicol
Arpit
jawad
Dhruvi Butti
neha
shindli
Michael Ratcliffe
Laphets
Brian Hackett
Ciure Andrei
Andrea Marchesini
Sebastian Hengst
J.C. Jones
longsonr
James Graham
Boris Zbarsky
Timothy Nikkel
Coroiu Cristina
Gurzau Raul
danielleleb
Andreea Pavel
Emilio Cobos Álvarez