Otherwise, when a glyph changes, we might end up doing too much work, destroying
the text-run and the observer that dirtied the frame, causing an assertion when
trying to delete it from the observer set.
MozReview-Commit-ID: LMQVr6pYFVM
This patch mainly consists of two parts, one for resolving and the other
for reordering.
In the resolving part, the added code stores the lowest embedding level
of all bidi formatting characters precede a frame to the bidi data of
that frame when necessary.
In the reordering part, virtual frame is restored from the information
stored above before asking the bidi engine to reorder frames
Collapsing a run of continuous virtual formatting characters into one
virtual character with the lowest embedding level among them should work
because a character with a higher embedding level than either of its
neighbors should not affect the reordering result of any other part of
the sequence. (No formal proof of this theorem, though)
MozReview-Commit-ID: LQjRu0mWsZP
--HG--
extra : source : 5d0cf1cbd270e9963d848a23b37528ed503ed6a0
This patch is mainly based on smontagu's wip patch. Some non-trivial differences:
* BidiParagraphData.mIsolateCount and related code are not added in this patch.
I investigated uses of this field in the wip patch, and it seems to me none of
them makes sense:
1. in the fast path of nsBidiPresUtils::ResolveParagraph, if there would be
any isolate character in the surrounding text, there must exist more than
one runs, which indicates the isolate count condition is redundant.
2. in handle of br frame in nsBidiPresUtils::TraverseFrames, based on my
understanding of "CSS Writing Modes Level 3" section "2.4.4. Paragraph
Breaks Within Embeddings and Isolates", the resolving should happen
unconditionally.
* {control,override}Char in nsBidiPresUtils::TraverseFrames are assigned
unconditionally when in a bidi inline container, so that we can properly
handle it when there are continuations. I suspect this was the reason of
regressions in dynamic reftests from the wip patch mentioned in comment 1.
MozReview-Commit-ID: LUdBAapA48e
--HG--
extra : source : 28fa56b841de689691375e8e2d5e56014921b48e
Masayuki suggests GetCharcterRectsInRange instead of first idea's API by part 2 implementation.
IME wants to need the width per character. Now nsTextFrame/nsIFrmae has only API to get point of string. So I want to add this method to calculate simply by comment #3.
If no text frame, I would like to return error due to no character. (Caller shouldn't call this API on non-text frame.)
MozReview-Commit-ID: LQHUTzhnGn
--HG--
extra : rebase_source : bc495493c7be73afb05489ad2169e8dcdd6e6da4
extra : histedit_source : e54a7c3bfb100765317a0c8a83b432d5f706ffe1
Before this change, SetupJustificationSpacing calls ComputeJustification
to compute how justification gaps are assigned to characters, and store
them in the PropertyProvider instance. When GetSpacing is called, those
information would be used to compute actual spacings from justification
before/after each character.
The bug is that, GetSpacing did not take gaps before the given range
into account when computing the spacing, which leads to unstable results
when range varies because of ignorance of accumulated error.
This patch changes it to eagerly computing the actual spacings inside
SetupJustificationSpacing, so that GetSpacing just queries the result
from mJustificationSpacings.
MozReview-Commit-ID: HoWqeOhD85w
--HG--
extra : source : 3838277a3883b6958293cb043bd14d8462bf4e8e
This patch defines two constants kSelectionTypeCount and kPresentSelectionTypeCount. The former is same as nsISelectionController::NUM_SELECTIONTYPES. The latter is kSelectionTypeCount - 1 for excluding SELECTION_NONE. The latter is useful in some loops which handle all selection types except SELECTION_NONE.
Note that this patch fixes a bug of nsFrameSelection. That doesn't treat SELECTION_NONE as a selection (see the definition of index), however, it defines redundant item and doesn't use it actually. Additionally, it computes invalid selection type in each loop. Therefore, without this patch, debug build hits MOZ_ASSERT() in ToSelectionType(RawSelectionType).
Note that these constants are defined as anonymous enum because we cannot define as const (or static) even with extern. If we'd try to do it, it caused link error or not available in nsFrameSelection.cpp as constant value since they were not initialized if they were initialized in nsSelection.cpp. Therefore, these constants are defined as enum items but using "k" prefix.
MozReview-Commit-ID: H6sH7NBEXlE
--HG--
extra : rebase_source : fd517d5fc2e2d5dc2f96313e2802fd1719817af7
This patch defines mozilla::SelectionType as an enum class. This is safer than nsISelectionController::SELECTION_* since setting illegal value to its variable is checked at build time. So, as far as possible, this should be used everywhere (but of course, this isn't available in scriptable interfaces).
And also this implements some useful methods for managing SelectionType and RawSelectionType which are implemented in layout/nsSelection.cpp because nsISelectionController is implemented by both PresShell and nsTextEditorState. Therefore, implementing one of them may make hard to find them. On the other hand, nsSelection.cpp is a better file name to look for them.
Note that this patch creates mozilla::Selection::RawType() for binding. Native code should keep using Selection::Type() but the binding code needs to use RawType() due to impossible to convert from SelectionType to RawSelectionType without explicit cast.
MozReview-Commit-ID: 81vX7A0hHQN
--HG--
extra : rebase_source : d9f88e217c713c60d1c2578ce6421c73ccba8650
mozilla::SelectionType will be an enum class. Therefore, we need to rename SelectionType with a word "raw" since it's a type for raw nsISelectionController::SELECTION_*.
MozReview-Commit-ID: K8SO0bbpv0Y
--HG--
extra : rebase_source : 56e3ac852657ef4795d718d2da09b16903c2e66c
mLineContainer is dereferenced shortly before and after the check, so it's
obviously not useful.
--HG--
extra : rebase_source : c8639197a10116e1251945f15edec6601a46265c
Unlike when returning an nsCOMPtr in a ternary operator or passing to a
function, I used .get() here, since the operation is actually unsafe and
deserves to be marked explicitly.
