-moz-user-focus: none didn't do anything useful for non-XUL until
bug 1868552. It seems nonetheless some sites specify it, which can cause
compat issues.
Let's hide this property from content, to avoid breaking those sites.
Differential Revision: https://phabricator.services.mozilla.com/D197253
-moz-user-focus: none didn't do anything useful for non-XUL until
bug 1868552. It seems nonetheless some sites specify it, which can cause
compat issues.
Let's hide this property from content, to avoid breaking those sites.
Differential Revision: https://phabricator.services.mozilla.com/D197253
Make it less error-prone by adding a HasProperty(AnimatedPropertyId&)
overload.
Also make the range checks a diagnostic assert rather than a non-fatal
NS_ASSERTION.
Differential Revision: https://phabricator.services.mozilla.com/D197045
This patch also updates the bug ID for a FIXME leftover from bug 1840478
to bug 1869476, since the same FIXME is added in D190758.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D191322
Differential Revision: https://phabricator.services.mozilla.com/D190758
This will make possible to animate custom properties on Gecko side. For now, the
animation code keeps only dealing with nsCSSPropertyID, so behavior is unchanged.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D190816
Differential Revision: https://phabricator.services.mozilla.com/D191059
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
This makes ticking the document timeline happens only when we make
forward progress. It seems otherwise we can end up with an extra no-op
tick which might resolve the ready time unexpectedly.
It's also cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D194406
Code like the one from comment 7 seems reasonable. Let's try to disable
prefixed transitions along with prefixed transforms in order to minimize
the compat fallout from CSS zoom.
While I was at it I also fixed the prefixed animation entries in the
property database and crashtests. But those aliases remain enabled.
Differential Revision: https://phabricator.services.mozilla.com/D192129
Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.
This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).
This is similar to what's described in the bugs comments, and seems to
work nicely in practice.
We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.
There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).
We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?
This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.
Over-all this is much simpler to reason about and I think we should try
to do this.
Differential Revision: https://phabricator.services.mozilla.com/D193583
Code like the one from comment 7 seems reasonable. Let's try to disable
prefixed transitions along with prefixed transforms in order to minimize
the compat fallout from CSS zoom.
While I was at it I also fixed the prefixed animation entries in the
property database and crashtests. But those aliases remain enabled.
Differential Revision: https://phabricator.services.mozilla.com/D192129
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This commits integrates the new animation triggered restyle counter into the existing tests to ensure that the counter matches the expected marker count.
Depends on D186714
Differential Revision: https://phabricator.services.mozilla.com/D186715
This commits integrates the new animation triggered restyle counter into the existing tests to ensure that the counter matches the expected marker count.
Depends on D186714
Differential Revision: https://phabricator.services.mozilla.com/D186715
In layout, we build a default `path("m 0 0")` for now. We will implement
it later.
Besides, we don't support compositor animations for `url()`, so we don't
have to serialize it for IPC.
Note:
`<url>` includes `url()` and `src()`. For now we only support `url()`.
We should revisit `src()` in Bug 1845390.
Differential Revision: https://phabricator.services.mozilla.com/D184429
This rejiggers a bit the transition event setup to not carry around an
InternalTransitionEvent. We create one once we're ready to dispatch it.
We can implement similar optimizations for animation and playback
events.
Also moves the markers out of line because those constructors were
getting rather unwieldy.
Differential Revision: https://phabricator.services.mozilla.com/D185425
As a bonus we now can throttle some additive and visibility animations
more properly, because before we couldn't compute a change hint for
those but now we don't need to.
Differential Revision: https://phabricator.services.mozilla.com/D185175
