- 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 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.
There's no need for this method to turn off blinking anymore. Its only
caller already calls SetCaretReadOnly to achieve the same effect. That
means we don't actually need the mIsBlinking flag after all.
--HG--
extra : rebase_source : 9d4c31282ed280c0f822f1d9f7fa8ae1c2ba6cab
A few things got mashed together here:
-- Inline KillTimer/PrimeTimer into their callers.
-- Instead of having to call StopBlinking and StartBlinking together,
change StartBlinking to ResetBlinking and have it set up
the correct blink state and reset the blink cycle.
-- nsCaret::NotifySelectionChange needs a SchedulePaint
-- nsCaret::DrawAtPosition needs a ResetBlinking
--HG--
extra : rebase_source : abc7fd78c4f20b787b212e1e3f13226a1ccff16b
This is the core of the whole patch set.
Now GetPaintGeometry/PaintCaret figure out on their own almost all the state
they need every time we paint. So when caret flags change, all we need
to do is SchedulePaint. We don't need to fiddle with mDrawn and most of the
logic in DrawCaret is obsolete. (In fact, it was duplicated by GetGeometry
and friends, and we're removing that duplication.) EraseCaret, CheckCaretState
and UpdateCaretPosition are also obsolete.
We need to have GetPaintGeometry/PaintCaret choose the correct content node
and offset, either getting them from the Selection or using specific data set by
DrawAtPosition. This logic, plus a bit of other code shared between them, is
put into the helper GetFrameAndOffset.
--HG--
extra : rebase_source : e777605dd2507ae043e9f82d0a30e23aa06e0c12
Instead of checking the mysterious mDrawn state (which is evil and will be
removed), let nsCaret::GetPaintGeometry take sole responsibilty for deciding
whether to draw. It takes the nsStyleUserInterface checks. It also needs to
check blink state, which is made possible by separating blink state into
the mIsBlinkOn flag.
--HG--
extra : rebase_source : 4a4796c37bc9ec7c25ffb2a320f9484cee1dc52f
This also fixes what appears to be a bug. MustDrawCaret returned true
when mShowDuringSelection is set even if the caret would otherwise be
hidden due a popup showing. That doesn't make sense.
--HG--
extra : rebase_source : e05e0892a85448dbc6666e23a0dbc7fa21a9c61e
This code is somewhat tricky. nsCaret::ComputeCaretRects was checking to see
if we have a bidi keyboard, and if so, what direction it's set to.
If the direction changed from the last direction seen for *this caret*,
we fired a SelectionLanguageChange notification on the caret's current
Selection. This looked bogus because the caret can be switched between
selections so it would seem some selections won't get a notification when
they should, but that's how it was. Also, when the SelectionLanguageChange
notification fired we then didn't draw the caret in that iteration, which
seems even more bogus.
This patch fixes all that by moving the logic to fire SelectionLanguageChange
out to GetPaintGeometry and firing the notification every single time without
trying to detect whether the state has changed or not. I carefully examined
the implementation of SelectionLanguageChange and I'm pretty sure it's
idempotent so this should be correct. That doesn't look like an
expensive function, and runs at most once per window paint, so I'm not
worried about perf. Because we now fire SelectionLanguageChange before
reading selection or frame state, it should be fine to carry on after
calling SelectionLanguageChange and drawing the caret based on whatever
changes SelectionLanguageChange has performed.
This also lets us remove mKeyboardRTL, which as noted above seems inherently
bogus.
--HG--
extra : rebase_source : 3ddfd10f6f30033e090e72b4bb43f2695218752e
Also, moves the "If the offset falls outside of the frame" check from
PaintCaret to GetPaintGeometry so we do less work in that case.
UpdateCaretRects is no longer needed.
--HG--
extra : rebase_source : 4b2925952a34d0388ae44c642129ce9015c367ea
This duplicates some code, but later patches will modify the callers and then
eventually we'll re-share common code.
--HG--
extra : rebase_source : 53f4756e87aadf22046972ef9102c190fbb35132
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
