Basically, we use the current target scroll position as the ready time for
scroll animations, so we don't need to wait until it gets painted.
In fact, it's unclear whether do we need play/pause pending status for
scroll animations, so we choose the natural way for now, and this should
match other browsers' behaviors.
Note:
We avoid puting the scroll animation into PendingAnimationTracker
in PlayNoUpdate() and Pause(). However, we may still "try" to remove
scroll animations from PendingAnimationTracker in some APIs just in
case if those APIs change the animations from using DocumentTimeline to
using ScrollTimeline. They should be revisited once we expose
ScrollTimeline to JS.
Differential Revision: https://phabricator.services.mozilla.com/D132750
Let's use the infinite iteration count and the alternative play direction
for now, so the scroll-linked animations will never be removed (and its play
state is always running) even if it reaches to the max scroll position.
Note:
1. We don't resolve finished promise at 100% now because it's unclear
whether we should resolve it for scroll animations or not.
2. This is not a perfect solution. We are planning to use the specified
timing in the future, so users can do more things on them, after the
spec defines them well.
Differential Revision: https://phabricator.services.mozilla.com/D132751
Per spec, "auto" represents the scrolling element of the document.
However, the scrolling element might be changed, based on the layout, in
quirks mode. Besides, the content of the root scroll frame is the root
element, instead of the scrolling element (e.g. body element) in both
standard and quirks modes. So now we define a special type, Scroller, to
represent the source of scroll-timeline, and use its |mType| to decide
which scroll frame we would like to use. In addition, hope this change let
us easier to implement nearest scroller.
Note: for auto scroller, we register this ScrollTimeline to the root
element, in both modes. Once we expose ScrollTimeline interface to the
script, we can rely on the |mType| of Scroller to return the correct
source element, whether it is scrolling element or not.
Differential Revision: https://phabricator.services.mozilla.com/D131578
We hook the rule into cascade data, and so we can look it up by timeline
name. Now we only use StyleScrollDirection from @scroll-timeline rule.
`source` and `scroll-offsets` are skipped now and use the default values
instead because I'm pretty sure the syntax will be changed in Bug 1733260,
and `scroll-offsets` may be obsolete because the spec proposal intents to
make it be always 0% ~ 100%.
Also, add some reftests for the default `source` and `scroll-offsets`,
and different `orientation`s.
Besides, we disable at-scroll-timeline-start-end.html in Gecko because
we don't support start/end descriptors, and there are too many
intermittents in it.
Differential Revision: https://phabricator.services.mozilla.com/D126452
For simplicity purposes, we don't consider OMTA for now. OMTA support
for scoll-timeline will be done in Bug 1737180.
However, in this patch, we would like to address:
if the geometic animations use scroll-timeline, we don't have to let it
affect the transform animations on the same animation target:
1. If we don't do scrolling, its geometric properties don't change, so no
effect on transform-like properties.
2. If we do scrolling, we may un-throttle the transform animations by
other ways, e.g. Keyframe::CanThrottle(). So we don't need to worry
about this.
Note: tests are in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D129103
Based on https://github.com/w3c/csswg-drafts/pull/4842, we define
"has finite timeline", which is a timeline that's not monotonically increasing.
We need this to update start time and hold time for scroll-timeline, so
we play scroll-linked animations as we expected, e.g. GetLocalTime() returns
the correct time value from GetCurrentTimeAsDuration().
Known issue: we still have bugs when setting "animation-play-state:paused".
Will do that in Bug 1741255.
Differential Revision: https://phabricator.services.mozilla.com/D131168
This patch focus on the timing computation of animation effects. We have
to compute the correct progress based on the scroll offsets. Now we
simplify the implementation only from 0% to 100%. The test cases will be
added in the last patch once we hook the scroll timeline to the CSS
animation.
Differential Revision: https://phabricator.services.mozilla.com/D129101
The basic part of the infrastructure of scroll-linked animations. This is
designed based on scroll-linked animation generated by CSS. We will
implement the timing computation and hook the ScrollTimeline to the CSS
animations in the following patches.
All the tests are in the patch that hooks ScrollTimeline to CSS Animation.
Differential Revision: https://phabricator.services.mozilla.com/D129100
We allow animating pseudo-elements like ::-moz-progress-bar (and we
treat them like regular elements).
Ideally we should store animations for these in the parent element as
well, so they survive reframes and such. But treating them as regular
elements right now means that we do animate them, but we never update
animations for them correctly because wrapper.rs assumed them to be
non-animatable.
Since it seems reasonable to keep allowing the animations to happen,
let's just correct the update code and add a test.
Differential Revision: https://phabricator.services.mozilla.com/D131794
The way CommitStyles called into servo caused it to call the closure
multiple times, and we were not dealing with that properly.
Handle the "was called" state internally.
Differential Revision: https://phabricator.services.mozilla.com/D131411
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
Before this change, in nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess
we call BaseRect::IsEmpty() for the returned value of GetFrameVisibleRectOnScreen,
unfortunately if the returned value size is (0x0), BaseRect::IsEmpty() returns
true thus we misthink the given nsIFrame is out of the visible area of the OOP
iframe where the nsIFrame lives.
Note that we have already done the same check for in-process cases in
IsFrameScrolledOutOfView [1].
The test case in this change fails without this change, suceeds with
the change. Though, to be honest, I don't know the reason those styles
, `display: grid`, etc. generate (0x0) sized frame even if decendants have
sized.
[1] https://searchfox.org/mozilla-central/rev/15de05f0e6d841cbc2ac66f8dcad72ebdada47f6/layout/generic/nsIFrame.cpp#11090-11094
Differential Revision: https://phabricator.services.mozilla.com/D126312
Before this change, in nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess
we call BaseRect::IsEmpty() for the returned value of GetFrameVisibleRectOnScreen,
unfortunately if the returned value size is (0x0), BaseRect::IsEmpty() returns
true thus we misthink the given nsIFrame is out of the visible area of the OOP
iframe where the nsIFrame lives.
Note that we have already done the same check for in-process cases in
IsFrameScrolledOutOfView [1].
The test case in this change fails without this change, suceeds with
the change. Though, to be honest, I don't know the reason those styles
, `display: grid`, etc. generate (0x0) sized frame even if decendants have
sized.
[1] https://searchfox.org/mozilla-central/rev/15de05f0e6d841cbc2ac66f8dcad72ebdada47f6/layout/generic/nsIFrame.cpp#11090-11094
Differential Revision: https://phabricator.services.mozilla.com/D126312
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
We support the setter of Animation.timeline, so it's possible to have a
null |mTimeline| when calculating the start value for off-main-thread
animations. If it's null, it must be different from the document
timeline, so in this case we don't set |mReplacedTransition|.
So let's move the assertion below the if-check of |mReplacedTransition|.
Differential Revision: https://phabricator.services.mozilla.com/D121675
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
It probably did something more useful in the past, but right now it's
only used to avoid throttling some overflow-causing animations.
It returns 0 everywhere except on Android (for some reason?), but in any
case it doesn't seem this would need to be a LookAndFeel integer, it
could just be a regular pref that we turn on for tests.
However the tests pass with this patch locally, so for now I'm not
adding a pref to replace it.
Differential Revision: https://phabricator.services.mozilla.com/D120871
So that now EffectCompositor::HasAnimationsForCompositor doesn't return true
for such cases, thus we will not accidentally try to generate
nsDisplayBackgroundColor display item for such animations (bug 1699890#c21)
and we will not generate nsChangeHint_RepaintFrame (bug 1701547) either.
Differential Revision: https://phabricator.services.mozilla.com/D115774
So that now EffectCompositor::HasAnimationsForCompositor doesn't return true
for such cases, thus we will not accidentally try to generate
nsDisplayBackgroundColor display item for such animations (bug 1699890#c21)
and we will not generate nsChangeHint_RepaintFrame (bug 1701547) either.
Differential Revision: https://phabricator.services.mozilla.com/D115774
We increase |jumps| for steps(<integer>,jump-both), and the <integer>
could be a large number, so we have to avoid the int overflow. Now we use
CheckedInt32 for it.
Also, `aPortion * aStepFunc.mSteps` may be out of the range of int32_t,
so we clamp it first and use CheckedInt32 for currentStep, too.
The error handling is pretty simple. We don't care about the result of
this unexpected behavior, so we simply roll the value back to the
original one.
Differential Revision: https://phabricator.services.mozilla.com/D112684
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
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
It should be called "Get" rather than "Lookup" because it returns
UserDataType. "Add" is called "Insert" in the other methods.
Differential Revision: https://phabricator.services.mozilla.com/D105470
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
Note that we can probably use mLastRefreshDriverTime directly in
DocumentTimeline::GetCurrentTimeStamp(), i.e. we don't need to use the refresh
driver there, but I'd preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D97823
Note that we can probably use mLastRefreshDriverTime directly in
DocumentTimeline::GetCurrentTimeStamp(), i.e. we don't need to use the refresh
driver there, but I'd preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D97823
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Changes to nsIScrollableFrame.h cause the world to rebuild which I find annoying.
This removes the inclusion into Element.h which is responsible for the
world-rebuilding and is relatively easy to eliminate. A bunch of usages of
nsIScrollableFrame get moved from .h files into .cpp files and I include the
header into .cpp files as needed.
Differential Revision: https://phabricator.services.mozilla.com/D90735
The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
CLOSED TREE
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
We just need this regardless of whether there appears checkerboarding or jank.
To avoid shrinking the content to the minimum-scale size on mobile environments,
we need to specify a meta viewport tag in this test.
Differential Revision: https://phabricator.services.mozilla.com/D75727
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
We just need this regardless of whether there appears checkerboarding or jank.
To avoid shrinking the content to the minimum-scale size on mobile environments,
we need to specify a meta viewport tag in this test.
Differential Revision: https://phabricator.services.mozilla.com/D75727
When transitioning visibility and opacity at the same time, we create
two effects, one animating opacity, and one visibility.
We're incorrectly throttling the visibility animation due to opacity,
because _that_ effect is not animating opacity, but the other one is and
thus doesn't get throttled.
Use HasAnimationOfOpacity() to check for this case. This is slightly
sketchy, because the first time we get through there we may not even
have started the opacity animation yet. However it kinda works, because
the fact that there's a (non-throttled, because of the
aEffect.HasOpacityChange()) opacity animation means that we'll tick both
of them, and unthrottle them next frame.
This seems better than the alternative which is never throttling
animations in opacity: 0 roots.
Differential Revision: https://phabricator.services.mozilla.com/D76405
This also requires changing the EffectCompositor to allow animations in print
and print preview, and setting up a document timeline for the cloned document
Differential Revision: https://phabricator.services.mozilla.com/D69069
The original site issue (https://trello.com/) seems not obvious on nightly
now. (See Bug 1301305 for more details.) So perhaps we could give this a
trial to disable this pref, for the better performance in other cases.
Differential Revision: https://phabricator.services.mozilla.com/D74278
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
When unhidding a ::marker element, we construct its generated item, and
then call StyleNewSubtree() on this generated item. During traversal, we
may update any animation related values in Gecko_UpdateAnimations(), which
may update the base styles for animation properties.
The test case is an animation segment from "null" to "inital" value. We
replace the "null" value with the base style value for the specific animation
property, so we can do interpolation properly.
(e.g. opacity: "null => initial" becomes "1.0 => initial")
If we don't update the animation related values in
Gecko_UpdateAnimations after generating ::marker, we may do
interpolation from "null" to "initial", which causes a panic.
Differential Revision: https://phabricator.services.mozilla.com/D73408
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
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
The basic idea is:
In the same 3d context (note: we use AutoPreserves3DContext to keep
this info), and we block the async animations of the ancestors of the ones
who don't prerender. Of course, and its later silbing frames and child
frames.
In order to to this, we keep a flag in Preserves3DContext, and set it
to false if the decision is No prerender, so we could force to block
async animations on its ancestors and descendants (and later silbings).
Differential Revision: https://phabricator.services.mozilla.com/D67686
--HG--
extra : moz-landing-system : lando
Converts dom.animations.offscreen-throttling to a static pref and removes the static function used to create the varcache pref.
Differential Revision: https://phabricator.services.mozilla.com/D67182
--HG--
extra : moz-landing-system : lando
Converts dom.animations.offscreen-throttling to a static pref and removes the static function used to create the varcache pref.
Differential Revision: https://phabricator.services.mozilla.com/D67182
--HG--
extra : moz-landing-system : lando
We should throw a DOMException SyntaxError when setting pseudoElement a
syntactically invalid string or an unsupported pseudo.
Differential Revision: https://phabricator.services.mozilla.com/D66321
--HG--
extra : moz-landing-system : lando
Callers should pass in UTF-8, since that's what the JS engine ends up with in the end anyway.
The various URL changes are because NS_NewURI converts incoming nsAString to
UTF-8 anyway. So we might as well do that up-front and then use the UTF-8
string for both the NS_NewURI call and the error-reporting if it fails.
Differential Revision: https://phabricator.services.mozilla.com/D65543
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
Dictionaries always need a BindingCallContext, because they can throw
MSG_NOT_DICTIONARY from Init().
We allow non-binding callsites to pass JSContext*, in which case they will not
get quite-as-nice error reporting.
Differential Revision: https://phabricator.services.mozilla.com/D64885
--HG--
extra : moz-landing-system : lando
We instantiate this class in various binding methods. Future patches will make
use of it to throw errors.
Differential Revision: https://phabricator.services.mozilla.com/D64883
--HG--
extra : moz-landing-system : lando
IgnoredErrorResult works well as the auto suppressor class and it's
cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D65810
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
Dictionaries always need a BindingCallContext, because they can throw
MSG_NOT_DICTIONARY from Init().
We allow non-binding callsites to pass JSContext*, in which case they will not
get quite-as-nice error reporting.
Differential Revision: https://phabricator.services.mozilla.com/D64885
--HG--
extra : moz-landing-system : lando
We instantiate this class in various binding methods. Future patches will make
use of it to throw errors.
Differential Revision: https://phabricator.services.mozilla.com/D64883
--HG--
extra : moz-landing-system : lando
Besides, we add the pref setup in the webidl, so if we turn it off,
iterationComposite and composite will always be the default values.
Differential Revision: https://phabricator.services.mozilla.com/D65437
--HG--
extra : moz-landing-system : lando
We add a stack based class and supress the exception of parsing easing
in the destructor, to avoid hitting the potential assertions.
Differential Revision: https://phabricator.services.mozilla.com/D64268
--HG--
extra : moz-landing-system : lando
This corresponds to the approach outlined in https://github.com/w3c/csswg-drafts/issues/4822
Specifically:
* Calling play() / pause() always triggers the "animation play state is being
overridden by the API" behavior (unless the method throws an exception).
* Setting the startTime or calling reverse() only triggers this override
behavior if it results in a change between a playState that is paused and a
playState that is not paused.
Differential Revision: https://phabricator.services.mozilla.com/D65100
--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
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
Boris Chiou
Kagami Sascha Rosylight
Alexandru Michis
Masayuki Nakano
Joel Maher
Emilio Cobos Álvarez
Sebastian Hengst
Gerald Squelart
Cristian Tuns
Jeff Muizelaar
Andreea Pavel
Hiroyuki Ikezoe
Matt Woodrow
Cosmin Sabou
Geoff Brown
Tooru Fujisawa
Andrew Halberstadt
Butkovits Atila
Iulian Moraru
Noemi Erli
Edgar Chen
Florian Quèze
Simon Giesecke
Mike Hommey
Andrew Osmond
smolnar
Kartik Gautam
Dorel Luca
Sylvestre Ledru
Ricky Stewart
Bogdan Tara
Andi-Bogdan Postelnicu
Markus Stange
Kartikaya Gupta
Jonathan Kew
Nathan Froyd
Brian Birtles
Cameron McCormack
tkhan
Brindusan Cristian
Masatoshi Kimura
Emily McDonough
Razvan Maries
Tom Tung
André Bargull
Kristen Wright
Stefan Hindli
Mark Banner
Boris Zbarsky
Arthur Iakab
Oana Pop Rus