- 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
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 is the start of the changes to caret-drawing proper.
The idea is to combine GetCaretFrame and GetCaretRect into a method
GetPaintGeometry which looks like GetGeometry but returns values
needed for painting (i.e. including bidi decorations, and returning
a null frame if we're not supposed to paint due to specific caret
state, e.g. in the "off" phase of the blink cycle).
Mostly a straightforward refactoring but there are a few interesting changes:
-- nsDisplayCaret stores its bounds instead of getting them from nsCaret on
demand. Eventually those bounds will not be stored in nsCaret at all.
-- nsDisplayCaret::GetBounds returns true for aSnap. nsCaret draws snapped
rects, so why not.
-- I removed "if (caretRect.Intersects(aDirtyRect))" in EnterPresShell.
As far as I can tell, this check is incorrect because it doesn't take
transforms into account. Since there's at most one drawn caret per window,
hence we do this at most once per paint, I don't think there's any real
performance advantage to having this check.
--HG--
extra : rebase_source : c98d3a5994478b482d19cc2e2ac83ab51bd17e00
The forward declaration of Selection in nsCaret.h will be used in later patches.
--HG--
extra : rebase_source : d1b749adac983c04d3365bb6bfb76a50101beeb5
