This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
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
This patch makes methods of FramePropertyTable and FrameProperties to be
simple template wrapper functions. Then it converts all references to
FramePropertyDescriptor to use "void" parameter to simulate the current
unsafe behavior.
SmallValueHolder is used for storing small values like int32_t, float,
which can fit in the size of a pointer directly, and thus no lifetime
management is needed.
--HG--
extra : source : 88b2723cddf119d73d8a442d8238b50406e9d604
