Also renames IsPositioned to IsAbsPosContainingBlock.
--HG--
extra : rebase_source : b412f6291d34e30e8d57e054645bd1e04f43593f
extra : histedit_source : 01a2bd57de4eec4ecf3f3712ee609d70ca14cda4
The caret movement code already handles unselectable text frames if we
happen to land in the middle of one in nsTextFrame::PeekOffsetCharacter/Word.
However, when performing frame traversal to find the next frame to jump
to, we don't remember if we skipped over an unselectable frame, which causes
us to jump one offset too much when the caret is on the boundary of
selectable and unselectable content. The test cases demonstrate the
scenario. Note that an <img alt=foo> is implemented by adding a
generated content to the inline frame representing it, so as far as
the caret movement code is concerned, both test cases are treated similarly.
Note that we need to do this only when moving the selection, and not
when extending it. We are adding an aExtend argument to
nsPeekOffsetStruct's constructor in order to be able to special case
that.
The caret movement code already handles unselectable text frames if we
happen to land in the middle of one in nsTextFrame::PeekOffsetCharacter/Word.
However, when performing frame traversal to find the next frame to jump
to, we don't remember if we skipped over an unselectable frame, which causes
us to jump one offset too much when the caret is on the boundary of
selectable and unselectable content. The test cases demonstrate the
scenario. Note that an <img alt=foo> is implemented by adding a
generated content to the inline frame representing it, so as far as
the caret movement code is concerned, both test cases are treated similarly.
Note that we need to do this only when moving the selection, and not
when extending it. We are adding an aExtend argument to
nsPeekOffsetStruct's constructor in order to be able to special case
that.
The change to GetAfterFrameForContent prevents the reframe that is part
of the chain of events leading to this bug, and thus fixes the bug on
its own. The change to GetBeforeFrameForContent seems desirable for
symmetry.
Note that patch 6 also independently fixes the reported bug.
This probably needs somewhat careful review. We should examine:
(1) what the rules for calling nsLayoutUtils::GetBeforeFrame and
nsLayoutUtils::GetAfterFrame are, and whether both (or neither)
need to be patched.
(2) What the rules are for which frame the GenConProperty() lives on,
and whether we should adjust nsIFrame::GetGenConPseudos() to either
do something more intelligent, or assert about callers.
(We should probably clean up some of these things in a followup bug.)
Since the symptom of this bug is (once patch 4 is in the tree) only
causing extra reframes, it can only be tested using the new API (from
bug 1115691) for observing reframes. I confirmed that the test for this
bug fails without the patch and passes with the patch (as noted by the
removal of its todo annotation).
This patch fixes the assertion on layout/generic/crashtests/600100.xhtml,
though I haven't investigated why.
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