The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
The main renaming was generated with the following python script:
```
import sys
import re
CAMEL_CASE_REGEX = re.compile(r"(^|_|-)([A-Z])([A-Z]+)")
DISPLAY_REGEX = re.compile(r"\bNS_STYLE_DISPLAY_([^M][A-Z_]+)\b")
def to_camel_case(ident):
return re.sub(CAMEL_CASE_REGEX,
lambda m: m.group(2) + m.group(3).lower(), ident)
def constant_to_enum(constant):
return "StyleDisplay::" + to_camel_case(constant) + ("_" if constant == "NONE" else "")
def process_line(line):
return re.sub(DISPLAY_REGEX,
lambda m: constant_to_enum(m.group(1)), line)
lines = []
with open(sys.argv[1], "r") as f:
for line in f:
lines.append(process_line(line))
with open(sys.argv[1], "w") as f:
for line in lines:
f.write(line)
```
And the following shell commands:
```
find . -name '*.cpp' -exec python display.py {} \;
find . -name '*.h' -exec python display.py {} \;
```
MozReview-Commit-ID: 91xYCbLC2Vf
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
nsTextFrame::GetCharacterRectsInRange() handles a character at the end offset of its content as in it. However, it causes odd result when the caller wants first text rect in the next nsTextFrame. E.g., if end of query range is at the next nsTextFrame's first character, currently, it returns the last character as in same line.
So, it should stop handling next frame's first character as in it.
MozReview-Commit-ID: 7WteerisrZp
--HG--
extra : rebase_source : 97653f1ed04a6a03373cd53613d92aba45fbe38b
New eQueryTextRectArray causes a lot of assertions in various automated tests. The cause is that nsTextFrame::GetCharacterRectsInRange() calls gfxSkipCharsIterator::AdvanceOriginal(1) at the end of the |for| loop *without* checking if the iterator has already reached to the end.
MozReview-Commit-ID: 3KFxA11uOUc
--HG--
extra : rebase_source : 407c47897cad8c2e4929ed1226073302faaecee2
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
