Basically, we call `ViewTransition::GetGroupKeyframes()` when any
computed values get changed on this element. For general CSS Animation
cases, we rebuild Keyframes because any of the property values (including
timing function) may be different.
Therefore, we have to do the similar things for dynamic group keyframes.
The size and transform are set from the captured elements, so I think they are
immutatable (and once they get changed, we should skip view transitions).
The only exception is `animation-timing-function`. We have to update the
timing function when invaliding the animations.
Note that `animation-composition` can also be keyframe-specific but we use
`Auto` value for it by default, and it means we are always using the
computed values from the element, so we don't have to worry about it.
Only timing function is special.
Differential Revision: https://phabricator.services.mozilla.com/D248366
It seems we forgot to use the size of snapshot containing block when
capturing the root element. Refactor the code a little bit to make sure
we do the check every time.
Differential Revision: https://phabricator.services.mozilla.com/D247514
We introduce `::-moz-snapshot-containing-block` pseudo-element to wrap
the view transition pseudo-element tree. This pseudo-element is only for
internal usage and cannot be accessed from outside.
Note that the related wpt,
`snapshot-containing-block-static.html`
`snapshot-containing-block-absolute.html`
are still failed because of Bug 1960755.
Also, add a test to check the snapshot containing block in the iframe,
and avoid hitting the issue of Bug 1960755.
There is no better way to verify that we do establish the fixed
positioning containing block, because it's unlikely to make the size of the
snapshot containing block be different from the viewport size on desktop
(note: this pseudo-element doesn't expose to the web), so I verified this
patch by changing the size of snapshot containing block manually in the UA
stylesheet, to see if it establish the fixed positioning containing block.
Differential Revision: https://phabricator.services.mozilla.com/D245648
Per spec, now we flush the update callback queue before scheduling the new
update callback in Setup() to make sure the previous update callbacks get
invoked before we do capturing.
Differential Revision: https://phabricator.services.mozilla.com/D241328
Otherwise, when calling getKeyframes(), we may serialize the empty
declaration (for height) which causes a debug assertion.
Differential Revision: https://phabricator.services.mozilla.com/D241308
Per spec, now we flush the update callback queue before scheduling the new
update callback in Setup() to make sure the previous update callbacks get
invoked before we do capturing.
The test is in css-view-transitions/start-view-transtion-skips-active.html,
which is not merged into Gecko yet, so I only can verify it in the try server.
Differential Revision: https://phabricator.services.mozilla.com/D241328
Otherwise, when calling getKeyframes(), we may serialize the empty
declaration (for height) which causes a debug assertion.
Differential Revision: https://phabricator.services.mozilla.com/D241308
The issue is just that the DOM order is not correct. Fix it by making
sure that the view transition names we capture are in order.
Differential Revision: https://phabricator.services.mozilla.com/D241009
The issue is just that the DOM order is not correct. Fix it by making
sure that the view transition names we capture are in order.
Differential Revision: https://phabricator.services.mozilla.com/D241009
Update the styles for writing-mode, direction, text-orientation,
mix-blend-mode, backdrop-filter, and color-scheme.
Also, update the test, pseudo-get-computed-style.html, because it
doesn't really match the spec. For example, we update the pseudo-element
styles after we invoke the update callback, so the computed values of
these pseudo elements should be the default values inside the update callback.
Now the behavior of Gecko is the same as that of WebKit.
Differential Revision: https://phabricator.services.mozilla.com/D240406
It is mostly working, but there are some tests that hit crashes and
asserts that we should sort out. For now, land it default-off.
This does implement other bits that are on by default tho, like creating
image frames for ::view-transition-new() pseudo-elements and so on. I
think that is fine (it's just that for now they are all transparent).
Differential Revision: https://phabricator.services.mozilla.com/D239382
The timeouts are bug 1950378. I'm looking into addressing that
(separately). Now we trigger more opacity animations and that
invalidates even after reftest-wait has been removed.
The layered-capture regressions are antialiasing in the borders, these
should go away once we use webrender for the snapshots, I hope.
Differential Revision: https://phabricator.services.mozilla.com/D239545
Also, we have to make sure we resolve or reject the finished promise in
`SkipTransition()` because `mPhase` may not be Done in
`CallUpdateCallback()`.
Besides, we have to update tests to wait for the load event of the popup
window because the original document of this popup window may get replaced
by a new blank one. In order to make sure we start view transitions in the
correct document, we have to wait until the popup window is loaded.
If we don't wait the load event, it may cause timeout because we destroy
the original document (which runs view tranistions) after some animation
frames, and so we keep waiting the new animation frames or any promises
of the view transitions (but they are skipped because the original
doucment has been destroy).
Note that the `resizeTo()` API may not work on mobile, e.g. Android, so
we may get timeout when waiting for `resize` event. That's why we expect
TIMEOUT in window-resize-aborts-transition.html and expect FAIL in
window-resize-aborts-transition-before-ready.html for android.
Differential Revision: https://phabricator.services.mozilla.com/D237995
Pretty bare bones (some properties missing), but this allows the
transition pseudo-elements to be in the right place.
We need to implement live capturing / integrate nical's work to display
the "new" image properly, but we'll get to that. Meanwhile this should
be uncontroversial.
Differential Revision: https://phabricator.services.mozilla.com/D238005
This should be rather uncontroversial. I filed bug 1947747 for inspector
support for this (which should work similarly than for presentational
hints).
Differential Revision: https://phabricator.services.mozilla.com/D237886
Basically, we have to schedule the performing pending operations after
activating the view transitions, and stop to do that once we don't have
active animations.
There is one known issue: we always timeout even if we activate the view
transitions successfully, so I clear the timeout once we start the animations.
Otherwise, we may always interrupt the long animations whose
durations are longer than `dom.viewTransitions.timeout-ms`. However, I
guess we may still need a timeout for it. We probably need to figure out
what to do in the future.
Note that `/css/css-view-transitions/paused-animation-at-end.html.ini`
is failed because we don't have any animations. This is probably blocked by
the dynamic UA stylesheet (Bug 1914324).
Also, update some other tests to avoid getting javascript errors:
`JavaScript error: , line 0: uncaught exception: Object`.
Differential Revision: https://phabricator.services.mozilla.com/D236215
Also, we put view transition psuedo element into
`AnimationUtils::IsSupportedPseudoForAnimations()`, and update the handling
of getting the pseudo request from a frame, to make sure we retrieve the
correct data for all supported psueod elements.
Besides, we have to update `SortingIndex` so we sort the events properly and
avoid hitting the assertion when using view-transitions.
The tests will be added when we support getAnimations() (Bug 1921109).
Differential Revision: https://phabricator.services.mozilla.com/D231536
This implements some basic snapshotting functionality, and hooks it to
the ::view-transition-old pseudo-elements.
Some tests that now fail because we start rendering the old snapshot,
but not at the right position, as for now the view transition pseudo
tree is all statically-positioned. That's all expected for now until we
implement the right styling for them, the top layer behavior, etc.
Main remaining question is how to get a hand on the right layer manager
from nsImageFrame::Destroy.
Differential Revision: https://phabricator.services.mozilla.com/D231977
First, we have to allow the functional parameter for named view
transition pseudo elements.
In this patch, we fix the case when `getComputedStyle()` resolve the style
lazily (i.e. call `Servo_ResolveStyleLazily()`) if its style is not available.
In this case, we have to make sure the matching function work.
We will make sure `aElement->GetPseudoElement(aPseudo)` work in the next
patch so we can retrieve the computed style from the pseudo elements
directly.
Differential Revision: https://phabricator.services.mozilla.com/D230354
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
