With the full patch series, all 4 pairs of tests pass. However, with
patch 10 removed from the patch series, all of the added tests fail
(probably through some interesting interactions).
The second set of 14 tests all fail (both with and without the patch)
because we don't start transitions when the before state is
display:none (either for style contexts coming out of the undisplayed
map or because we have no current style context because an ancestor is
display:none).
The patch makes all of the first set of 14 tests pass. Without the
patch, most of these tests fail, except for the 4 testing e1 and the
root.
I presume the four tests that pass prior to the patch pass because the
restyle actually occurs and starts the transition (which is stored on
the element) before the style context is destroyed.
This isn't actually a problem for this patch series because the root
element can't have an ancestor that's reframed because it has no
ancestors, and reframes of the element itself trigger a restyling
operation that does actually start transitions.
That said, later patches in this bug hook in to ResolveStyleContext, and
other things might as well in the future, thus the FIXME.
- Verify that instant scroll-behavior is synchronous.
- Verify that smooth scroll-behavior is asynchronous.
- Verify that smooth scroll-behavior is triggered by CSSOM-View DOM methods.
- Verify that instant scroll-behavior interrupts smooth scroll-behavior
animation.
- Verify that smooth scroll-behavior is not framerate dependant.
- Verify that smooth scroll-behavior physics simulations used by animations
converge and allow the animation to reach completion.
- CSSOM-View scroll-behavior smooth scroll animations must produce the same
results indendently of frame-rate:
- Reference samples of scroll position for each frame are captured from a
smooth scroll at 120fps for variations in X-Distance, Y-Distance.
- Test samples are captured from an animation with the same parameters at
varying framerates.
- Variance in position at each sampled interval is compared to the 120fps
reference. To pass the test, the position of each test sample must match
the reference position with a tolerance of one test sample frame's range
of motion. This range of motion is calculated by the position delta of
the reference samples one test frame duration before and after.
- The duration of the reference sample animation and the test sample
animation must match within 1 frame to pass the test.
- The simulation driving the animation must converge and stop on the
destination position for the test to pass.
- Updated ScrollTo method in nsGlobalWindow to accept a
mozilla::dom::ScrollOptions parameter to select between the instant
and smooth MSD motion.
- Updated WebIDL binding boilerplate scrolling functions in nsGlobalWindow
to pass the correct value of mozilla::dom::ScrollBehavior to the
implementation and functions, activating smooth scrolling.
- These functions will need to be updated again to support the scroll-behavior
CSS property in Bug 1010538.
The assertion in nsTimeStamp::operator >= occasionally fails due to a null RHS
timestamp when called from AnimationPlayer::GetCurrentTimeDuration, which, in
turn, is called from AnimationPlayer::SetSource.
The issue appears to be that we're not correctly initializing
AnimationPlayer.mPlayState. This value can be running (0) or paused (1) but we
only ever compare against the paused state (i.e. every other value is
effectively treated as running). If we don't initialize this we can end
up in the paused state but with mPauseStart not set to a valid (non-null)
TimeStamp. This creates an inconsistent state since we assume that when we're
paused mPauseStart is non-null, hence the assertion fails.
This gets tickled because, since bug 1040543, we call
AnimationPlayer::SetSource from nsAnimationManager::BuildAnimations *before* we
set mPlayState and mPauseStart.
This patch initializes mPlayState to the running state so we don't accidentally
end up in an inconsistent state.
It also removes some (now unnecessary) initialization of mPlayState and
mPauseStart from nsTransitionManager::ConsiderStartingTransition.
In future we could also consider reworking nsAnimationManager::BuildAnimations
so that we call SetSource on the new animation player *after* setting up its
play state. That may be more correct and would further avoid this problem but
may not be necessary since all that code is likely to change in the near future.
This also includes a test that mozMatchesSelector is still exposed and works.
--HG--
rename : js/xpconnect/tests/chrome/test_mozMatchesSelector.xul => js/xpconnect/tests/chrome/test_matches.xul
rename : js/xpconnect/tests/mochitest/file_mozMatchesSelector.html => js/xpconnect/tests/mochitest/file_matches.html
