- 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.
--HG--
extra : rebase_source : 194f6c9364e316ea21cf1e74ab6f7542ee94edb8
- 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.
--HG--
extra : rebase_source : 7c9ce94d09fed5c4aea63442d683876c0a9a2e50
This is the actual fix for the bug. This changes the vertical sizing of
inline ::first-letter frames to work like inlines (and size based on
font metrics), so that the line-height calculation that happens later
will produces the same results as inlines would produce.
In the case we're concerned with of having a text frame child that's
0x0, this changes the inline ::first-letter from from being 0x0 to
having a height that is determined from the font metrics.
There's no need for these calls to be done in the inline ::first-letter
codepath.
In particular, nsLineLayout::ReflowFrame (called a few lines above)
calls SetRect and DidReflow, while nsLineLayout::RelativePositionFrames
(which is called at the end of inline reflow) calls
FinishAndStoreOverflow.
This patch makes no changes other than duplicating the code previously
after the if/else on both branches of the if/else.
The next two patches in this series will completely rewrite the half in
the non-floating (i.e., inline) codepath (the else branch).
This changes this code to do things in the normal way, which is to use a
separate nsHTMLReflowMetrics for each Reflow, rather than (as this code
was) reusing the one for the nsFirstLetterFrame for its text frame
child.
This test fails without the patch series because the border around the
test is too tall, but patch 5 reduces the height of the border in the
test so that it matches the reference.
This matches patch 2, and also fixes an incorrect use of eRestyle_Self
on the parents of pseudo-elements in order to restyle those
pseudo-elements, where it would not previously have been effective.
This should all be temporary, since this code can go away with bug
960465, when animation phases are removed.
This (like patch 1) posts restyles directly to the pseudo-element
content nodes, which is a new thing as of this bug. Previously we'd
have posted eRestyle_Subtree restyles to the pseudo element's real
element (i.e., the parent of the pseudo-element content node).
This changes the way we post animation restyles for ::before and ::after
pseudo-elements with animations on them.
This (like patch 2) posts restyles directly to the pseudo-element
content nodes, which is a new thing.
This isn't needed right now since AddStyleUpdatesTo is currently only
used when updating main-thread-suppressed animations running on the
compositor. However, it will be needed once we depend on
AddStyleUpdatesTo for bug 960465. And it will have an effect now since
AddStyleUpdatesTo actually adds all animations rather than only the ones
that are suppressed from running on the main thread.
