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
The forward declaration of Selection in nsCaret.h will be used in later patches.
--HG--
extra : rebase_source : d1b749adac983c04d3365bb6bfb76a50101beeb5
This patch started an attempt to remove nsFrameSelection.h from nsCaret.h
and metastasized into a rather large refactoring patch that removed it
from some other header files as well, and changed nsFrameSelection::HINT
into a global-scope enum with better names. I also converted bools
into CaretAssociationHint in a few places where that was appropriate,
but there are still some more places (GetChildFrameContainingOffset)
where bools need to be converted. I figured this patch was big enough already.
--HG--
extra : rebase_source : cc618ef60e707e1360644340a2648de389383da0
GetGeometry is used in two different ways. Sometimes it's used to get
information about a particular caret. Sometimes it's used to get
information about a particular selection that's not associated with
a caret. Splitting GetGeometry into a non-static version for the former
and a static version for the latter makes this more clear. Also it saves
code since for the latter version we don't have to get an nsCaret first.
--HG--
extra : rebase_source : b7730dac56b308a82b79b175749234c9a92b6f59
We don't need to store the blink rate. Instead we can just fetch it whenever
we need it. However we do need a flag to handle the case where
nsCaret::DrawAtPosition disables blinking.
--HG--
extra : rebase_source : 4f36825a8e22edd3a2e37edb1fae5675c85adadd
I was inspired by the previous patch to remove FrameLayerBuilder.h from
nsDisplayList.h too.
--HG--
extra : rebase_source : b34a01bea5865da4737817e2396b98d54cc6d1bf
mCaretAspectRatio doesn't need to be stored. We can recompute it
whenever we need it.
--HG--
extra : rebase_source : 065a6996e920800edf5cbcc7f072f0439ef84553
mCaretWidthCSSPx doesn't need to be stored. We can just recompute it
whenever we need it.
--HG--
extra : rebase_source : 850b556651afade0da543e281e5fa54235969ab4
These used to be needed for linking with non-libxul builds, but are no
longer needed. The obsolete comment is fixed in a later patch.
--HG--
extra : rebase_source : 034f69b647bd64d4353e51a15e166094b7b2e638
To make it more clear what's going on, make CaretBlinkCallback protected
and reorder the public methods to put the state-changing "API" methods first.
--HG--
extra : rebase_source : fddf0ea4b9269b2d431d0b75c40f99a9140138a1
GetCaretFrameForNodeOffset only uses the nsFrameSelection and mBidiUI
from its nsCaret. For mBidiUI we can just get the pref directly whenever
we need it. By modifying GetCaretFrameForNodeOffset to take nsFrameSelection
as a parameter, we can make it static to make it clear it isn't really
related to the state of the nsCaret.
This may also fix a bug in Selection::GetPrimaryFrameForFocusNode where
things would go unexpectedly wrong if mCaret is temporarily observing
a different selection to the Selection.
--HG--
extra : rebase_source : cdd59f6e20cd1060bc5d2325cb3adb5e5c4a1d2c
Fixes the assertion failure with text:
"###!!! ASSERTION: Wrong line container
hint: '!aForFrame || (aLineContainer == FindLineContainer(aForFrame) ||
aLineContainer->GetType() == nsGkAtoms::rubyTextContainerFrame ||
(aLineContainer->GetType() == nsGkAtoms::letterFrame &&
aLineContainer->IsFloating()))', file
/home/sgbowen/builds/mozilla-central/layout/generic/nsTextFrame.cpp, line 1259"
which occasionally appears when opening pages with ruby or when running ruby
reftests.
Updates the manifest for ruby reftests to the current expectations (adjust
assertion counts, etc.)
To account for spacing between bases or text boxes during reflow, the line
layout which manages the bases updates its inline direction coordinate based on
the preferred inline size for the corresponding text boxes. Next, the base is
reflowed at the correct inline coordinate. Each paired text box is then also
reflowed at the proper inline position determined by (1) the current position of
its corresponding base and (2) its own preferred width.
In computing intrinsic widths, accounting for spacing is less complicated. The
minimum intrinsic width is the width of the widest ruby column, and the
preferred intrinsic width is the sum of all the ruby column widths. Each ruby
column width is the maximum width of its base box and text boxes. These
individual widths are determined using GetPrefISize on the base and text boxes.
Ruby base container frames store a list of pointers to the ruby text container
frames in the segment they denote. This list of pointers is created in the ruby
frame reflow method before calling the reflow method for the ruby base
container. The list exists and is used only during reflow of the main ruby frame
and is cleared before returning from reflow.
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.
As the third step in dividing functionality between AnimationPlayer and
Animation this patch moves the mIsFinishedTransition member and related methods
from AnimationPlayer to Animation.
At the same time we rename SetFinishedTransition to SetIsFinishedTransition.
As the second step in dividing functionality between AnimationPlayer and
Animation, this patch moves the AnimationTiming member from AnimationPlayer to
Animation.
Most of this patch is simply moving code around. However, one significant
functional difference is that Animation::GetLocalTime() uses the mParentTime
member which is set when the Animation is updated by the player it is attached
to.
Other less significant differences are:
* AnimationPlayer::GetLocalTime is renamed to GetCurrentTimeDuration
In Web Animations, animation players have a (writeable) "current time" and
animations have a (read-only) "local time".
We would call the method simply "GetCurrentTime" (instead of
"GetCurrentTimeDuration") but GetCurrentTime is the name of the method used in
the content-facing API where it returns a double.
* "IsCurrent" is defined on both AnimationPlayer and Animation with the version
in AnimationPlayer serving mostly as a convenience shortcut to the version on
Animation.
* Animation::GetComputedTiming (previously on AnimationPlayer) now makes the
timing parameter optional since most of the time it is not needed.
As the first step in dividing the functionality currently contained in
AnimationPlayer between AnimationPlayer and Animation this patch moves the set
of keyframe properties to the Animation.
These properties are returned from the Animation by a couple of Properties()
methods that provide direct access to the member variable. In future it is
anticipated that the non-const version will be replaced with an appropriate
setter function. This will likely happen when we implement a separate
KeyframeEffect object as defined by the Web Animations API.
With regards to error checking, nsAnimationManager checks the result of
AnimationPlayer::GetSource() and handles the case where it is nullptr.
nsTransitionManager, however, simply asserts that GetSource() is never null much
like it also asserts that there is only one property with one segment in the
animation. Eventually this code should be made more generic which will probably
happen in bug 999927.
