This patch is written by the following script with some manual adjustment to
the comment in nsRubyTextContainerFrame.cpp and nsRubyFrame.cpp, and
nsColumnSetFrame's constructor.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "nsReflowStatus *([a-zA-Z0-9]*) = NS_FRAME_COMPLETE" "nsReflowStatus \1"
rename "([a-zA-Z0-9.*]*) *= NS_FRAME_COMPLETE;" "\1.Reset();"
rename "([a-zA-Z0-9.*]*) == NS_FRAME_COMPLETE" "\1.IsEmpty()"
MozReview-Commit-ID: 9tqQAHvdQex
--HG--
extra : rebase_source : 3119776946dc2c8350098b7bf9f3ceff29bdffb5
To preserve the semantics, Reset() is called to clear other bits in the
status prior to set the incomplete bit. Though some of them might not be
necessary.
MozReview-Commit-ID: InNDwcpp28A
--HG--
extra : rebase_source : 833e44a5dbb447d82c67f715cd5b0b2e97a5c62d
NS_INLINE_MAKE_BREAK_TYPE is used only in BRFrame. Delete it, too.
MozReview-Commit-ID: GC4vF0GFsAD
--HG--
extra : rebase_source : d7727fe41410a8998142d9ded8dcd8ae9c2a780f
NS_INLINE_LINE_BREAK_BEFORE() was replaced by the help of the following script.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename " = NS_INLINE_LINE_BREAK_BEFORE\(\);" ".SetInlineLineBreakBeforeAndReset();"
MozReview-Commit-ID: mz6L8zay7q
--HG--
extra : rebase_source : fddffa1288c7a52c7245aec0839a65f8d1d3f008
I think there are three advantages of this change:
1. removes some dependencies from layout / painting code to pre-computed
value stuff in the style system;
2. makes it easier to audit usage of specific fields in style structs
(which is probably a side effect of the first one);
3. potentially improves performance since it doesn't go through the
unnecessary general logic in ExtractComputedValue.
Also, combined with the part before, we get a unified list for visited-
dependent properties so that we can ensure the assertion here and the
style difference calc code are consistent.
MozReview-Commit-ID: 5B9aN7CfRgI
--HG--
extra : rebase_source : ac80eaea2474b9ec4b47b1cc9a5bdd2e61f6ec4d
Trim trailing whitespaces for files that are touched in this bug:
gfxTextRun.h
gfxTextRun.cpp
nsTextFrame.cpp
nsCSSProps.cpp
MozReview-Commit-ID: FmiW2QiCoFv
--HG--
extra : rebase_source : cbc9ae8c3c4410d1fe79c027d4ccf11b45c8bd19
This is the bulk of the changes.
- DisplayItemScrollClip is removed. Instead, we will have 1) ActiveScrolledRoot
and 2) DisplayItemClipChain.
- ActiveScrolledRoot points to a scroll frame and allows traversing up the
scroll frame chain.
- DisplayItemClipChain is a linked list of clips, each clip being associated
with the ActiveScrolledRoot that moves this clip.
- Each display item has an ActiveScrolledRoot and a clip chain.
- nsDisplayItem::GetClip returns the item of the clip chain that scrolls with
the item's ASR. The separation between "regular clip" and "scroll clips"
mostly goes away.
- Tracking clips in the display list builder's clip state happens very
similarly to how regular clips used to be tracked - there's a clip chain for
content descendants and a clip chain for containing block descendants. These
clip chains are intersected to create the combined clip chain.
- There are strict rules for the ASR of a container item: A container item's
ASR should be the innermost ASR which the item has finite clipped bounds with
respect to.
- At some point in the future, ASRs and AGRs should be reunified, but I haven't
done that yet, because I needed to limit the scope of the change.
MozReview-Commit-ID: KYEpWY7qgf2
--HG--
extra : rebase_source : c727f6300a35463750639e165bfa37374c06b851
For the non-owning pointer usage like iterating SelectionDetails's linked
list, it's sufficient to use SelectionDetails*.
MozReview-Commit-ID: 7PCFhD6Iz8j
--HG--
extra : rebase_source : 2d26edd513a402384e26719b3c0b5362d7a4ebb8
1. Rename these functions to agree with Mozilla coding style.
2. Use singular naming instead of plural naming since each of these functions
returns an iterator pointing to a singular line.
3. Rename line() and rline() to BeginLineFrom() and RBeginLineFrom(), which
shall improve the readability.
MozReview-Commit-ID: txZjVnv9Yb
--HG--
extra : rebase_source : b4dae99ab7bf751bd9974616f8f8e6dfe6248fc2
DETAILS ON THE CLEANUP:
* In nsFrameTraversal.cpp:
- Whitespace fix.
- Remove a useless nullptr assignment.
- Use "=" to initialize a nsCOMPtr, per coding style guideline ("initialize variables with nsFoo aFoo = bFoo and not nsFoo aFoo(bFoo)").
* In nsPresShell.cpp:
- Wrap a longish assignment to 2 lines (since next patch will make the first line longer, which would push the whole thing over 80 characters if it weren't wrapped).
- Add braces around "if" body.
* In nsTextFrame.cpp:
- Remove a useless nullptr assignment.
- Move the "metrics->GetThebesFontGroup()" call slightly earlier, so it happens *before* we've implicitly transferred ownership the object pointed to by "metrics".
- Add a code-comment.
MozReview-Commit-ID: LG6vgOmM9MK
--HG--
extra : rebase_source : 7754d4edefb09ae7992275b9dcb7e84371955d9c
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
