The test-case in the bug does something interesting, where it causes a
transition on the parent by removing a CSS rule, and that causes us to
transition text-underline-offset on our ::marker, via the magic of
font-size-relative properties.
text-underline-offset, while it gets inherited from ::marker, is not a
valid CSS property to specify on marker per spec, so we trim it here:
https://searchfox.org/mozilla-central/rev/899bbd9e5a0d6de9bb9f068c48b1445c7905d9cf/servo/ports/geckolib/glue.rs#5709-5712
And that causes us to create a transition with an empty effect and
everything goes downhill from here.
For now, just bail out in a nicer way than we were doing. I still need
to look into whether we should handle inherited transitions differently
from non-inherited one in this case...
I think our behavior after this patch would be correct for the test-case
(because text-underline-offset would transition on the parent and
::marker would inherit it). If you specify transition only on the marker
we'd refuse to transition (which I guess it is somewhat of a sensible
behavior).
Differential Revision: https://phabricator.services.mozilla.com/D105124
The motivation here is that we will want to call CSSTransition specific
functions, e.g. updating the start value of a given CSSTransition with
the latest value of the CSSTransition on the compositor, from somewhere
not in layout/style. Unfotunately nsTransitionManager.h is not exposed
and we will never want to expose it since it's purely for layout/style
stuff.
Depends on D73570
Differential Revision: https://phabricator.services.mozilla.com/D73571
The motivation here is that we will want to call CSSTransition specific
functions, e.g. updating the start value of a given CSSTransition with
the latest value of the CSSTransition on the compositor, from somewhere
not in layout/style. Unfotunately nsTransitionManager.h is not exposed
and we will never want to expose it since it's purely for layout/style
stuff.
Differential Revision: https://phabricator.services.mozilla.com/D73571
Since mTransitionProperty keep holding the original transition property even if
the target effect or keyframe was replaced by others. We need to make sure the
current transition is runnable on the compositor, i.e. having the effect and
keyframes and one of the properties is runnable on the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D73586
P2 removed IsTimerPrecisionReductionEnabled and thus removed the check for RFP
pref. While most ReduceTimePrecision* functions are fine with that because
GetTimerPrecisionType checks that, the two ReduceTimePrecision*RFP functions
miss the check.
This patch mainly cover the check for that two functions and rename them to
*RFPOnly since they only use RFP when the pref is on.
Depends on D64324
Differential Revision: https://phabricator.services.mozilla.com/D66734
--HG--
extra : moz-landing-system : lando
To support checking CrossOriginIsolated in performance.now(), we need to:
- Add new types to TimerPrecisionType for nsRFPService
- System, HighResAllowed are added
- All is renamed to Normal
- Introduce a set of Reduce methods which require isSystemPrincipal and
CrossOriginIsolated to be passed and decide the TimerPrecisionType later
- Original Reduce methods should only be called when callsites know the
TimerPrecisionType. Otherwise, they should call the new methods.
- The following patches will use new methods
Differential Revision: https://phabricator.services.mozilla.com/D63293
--HG--
extra : moz-landing-system : lando
These are no longer needed and they make assumptions about the shape of the
keyframes/properties which are not valid if the keyframes are replaced.
Differential Revision: https://phabricator.services.mozilla.com/D64520
--HG--
extra : moz-landing-system : lando
This is needed so that later we can make the effect of transitions replaceable.
Note that the test added in this patch will fail without the code changes in
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D64519
--HG--
rename : layout/style/test/test_transitions_replacement_on_busy_frame.html => layout/style/test/test_transitions_replacement_with_setKeyframes.html
extra : moz-landing-system : lando
This is yet to be specified although it is already tested in CSS Transitions
WPT. It is also needed in order to produce the expected reversing behavior when
CSSTransition's keyframes are replaced.
Differential Revision: https://phabricator.services.mozilla.com/D64510
--HG--
extra : moz-landing-system : lando
These are no longer needed and they make assumptions about the shape of the
keyframes/properties which are not valid if the keyframes are replaced.
Differential Revision: https://phabricator.services.mozilla.com/D64520
--HG--
extra : moz-landing-system : lando
This is needed so that later we can make the effect of transitions replaceable.
Note that the test added in this patch will fail without the code changes in
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D64519
--HG--
rename : layout/style/test/test_transitions_replacement_on_busy_frame.html => layout/style/test/test_transitions_replacement_with_setKeyframes.html
extra : moz-landing-system : lando
This is yet to be specified although it is already tested in CSS Transitions
WPT. It is also needed in order to produce the expected reversing behavior when
CSSTransition's keyframes are replaced.
Differential Revision: https://phabricator.services.mozilla.com/D64510
--HG--
extra : moz-landing-system : lando
In order to store the different combinations of (Element, PsuedoStyleType)
pairs, including (nullptr, ::before/::after), we drop Maybe<> and use
OwningAnimationTarget directly.
Differential Revision: https://phabricator.services.mozilla.com/D62666
--HG--
extra : moz-landing-system : lando
People keep adding useless null-checks and it was not clear what the consensus
was from bug 1441165, but this should be unobjectionable I guess.
Differential Revision: https://phabricator.services.mozilla.com/D46781
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
Currently we avoid posting animation restyles when unbinding an element by
removing the element from the document before deleting its animation
collections. As a result, when canceled animations go to post a restyle, they
can't find a pres context and give up posting a restyle.
However, this is problematic for two reasons:
* It means we can't remove such canceled animations from the
PendingAnimationTracker if they are present there (i.e. it regresses the fix
from bug 1223445).
* It means we can't post cancel events for such animations/transitions since we
can't lookup the appropriate AnimationEventDispatcher.
In the next patch in this series we will change that order to fix the above
problems but before we do that, we need to introduce another mechanism to make
sure that we don't post restyles when unbinding an element or else we will
regress bug 1396041.
This patch does that by introducing a flag which causes us to not post restyles
when we are doing DOM surgery. For all other cases we actually _do_ need to post
restyles in order to update the style correctly.
Without this patch, layout/style/crashtests/1396041.html would fail after
applying the next patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D28021
--HG--
extra : moz-landing-system : lando
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
First, we generate StyleComputedTimingFunction by cbindgen from Rust, and use
it in nsTimingFunction, so we could copy it directly without handling
the different memory layout. However, we have to rewrite the
nsTimingFunction and mozilla::ComputedTimingFunction for this.
Second, the rust-bindgen seems cannot generate the correct generic members
from complex C++ templates, especially for the nested template struct,
(https://github.com/rust-lang-nursery/rust-bindgen/issues/1429)
So we have to hide StyleTimingFunction to avoid the compilation errors.
Depends on D9312
Differential Revision: https://phabricator.services.mozilla.com/D9313
--HG--
extra : moz-landing-system : lando
For each file touched in this patch, the file had an #include for nsContentUtils.h, but no other mentions of the string "nsContentUtils", nor any mention of its "ScriptBlocker"-related types. So these files likely don't need their nsContentUtils.h include anymore, and we can remove it to get a marginal win on build time/complexity.
Differential Revision: https://phabricator.services.mozilla.com/D3370
--HG--
extra : moz-landing-system : lando
The loop was mutating the nsCSSPropertyID used to guard the exit, which is
obviously wrong.
This branch is pretty rarely taken, since people don't usually specify `all` as
a transition property other than the first, for which case we take the fast path
with `checkProperties = false`. Our test-suite failed to catch this.
Added a crashtest that hangs without this patch.
The reason bug 1478990 regressed this is because it changed the order of
nsCSSPropertyID so that `p` actually went backwards causing the infinite loop,
but the bug was introduced (by me, whoops) in bug 1309752.
Differential Revision: https://phabricator.services.mozilla.com/D2552
MozReview-Commit-ID: Ii3D1FaZ31R
--HG--
extra : source : 78be4bbf4b050f6614bb9f4115f57fb61f4890df
The setup is that AnimationValue only contains physical properties, and
we physicalize when building keyframes and transitions.
MozReview-Commit-ID: 9dI20N0LFrk
Before this change, the test in this commit fails. The received events order
is;
1) cancel
2) transitioncancel
3) transitionstart
4) finish
MozReview-Commit-ID: 8liTFXime6e
--HG--
extra : rebase_source : 3c68ef330b1f263afa2fad9670a30b351b8dbf28
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Razvan Maries
Simon Giesecke
Botond Ballo
Tom Tung
Brian Birtles
Oana Pop Rus
Boris Chiou
Ryan Hunt
Sylvestre Ledru
Diego Pino Garcia
Olli Pettay
Daniel Holbert
Hiroyuki Ikezoe
Jeff Gilbert
Xidorn Quan
Dorel Luca
Miko Mynttinen
arthur.iakab