From the "NS_ASSERTION(mFloatManager)" statement in BlockReflowInput's
constructor, we know that BlockReflowInput's mFloatManager is always valid
and equals to aReflowInput.mFloatManager. Therefore, we could just use
ReflowInput's float manager in BlockReflowInput.
Due to the removal of BlockReflowInput's mFloatManager, the logic which
resets mFloatManager near the end of nsBlockFrame::Reflow() is removed as
well. It's safe because beyond that point, no other logic involves floats,
and |state| (i.e. BlockReflowInput) lives only on the stack.
MozReview-Commit-ID: 3dwXMnWkEI6
Per spec, float positioning and stacking is not affected by defining a float
area with a shape.
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
So all the call sites of GetFloatAvailableSpace() related to adding a
float are replaced by GetFloatAvailableSpaceForPlacingFloat().
<shape-box> with border-radius will be implemented in next part.
MozReview-Commit-ID: 1RXEeXDhdWo
In nsBlockFrame::PlaceLine(), we query the float available space by
using the line's BSize(), which may cause the line to reflow again due
to available space shrunk.
The first issue lies in the second reflow. That is, we do not leverage
the line's BSize() computed in the first reflow to query the float
available space when updating the inline reflow engine in
BlockReflowInput::AddFloat(). So some tall inline elements could still
overlap the floats as in the first reflow.
To solve this, we cache current line's BSize so that it could be
used to update the inline reflow engine when redo the line.
Another issue is in nsBlockFrame::PlaceLine(). When determined whether
the available space is shrunk, we use the float manager's state *before*
placing the line. So if current line has floats, they're not considered.
To solve this, we use the current set of floats to get the float available
space for comparison, and leave the original aFloatAvailableSpace to provide
the information when redoing the line.
MozReview-Commit-ID: GqqNlphgxYS
This patch is based on bug 1291110 comment 29, but |aCanGrow| is preserved,
since the set of float available spaces we'll be testing in Part 4 are
difference from the one we enforced here.
MozReview-Commit-ID: LswbIaRukVR
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
Since we're converting LineReflowStatus to an enum class, the "default:" branch
of LineReflowStatusToString() could be removed as well. In this way, we can add
protection at compile time (warning) instead of runtime (assertion).
MozReview-Commit-ID: 8Ul0eCxqSTR
This is a pre-patch that uses LineReflowStatusToString() function instead of
LineReflowStatusNames array to support debugging. With this patch, we could
easily regain debugging support from LineReflowStatusToString() while converting
LineReflowStatus to an enum class.
MozReview-Commit-ID: K2AzZ2zI69p
Per bug 1299753 comment 20, SetFlags() is designed for flag propagation
to continuations during block reflow. To avoid misuse, I expand
SetFlags() directly in the only reasonable caller nsBlackFrame::Init(),
and replace other usages by AddStateBits().
MozReview-Commit-ID: GsbE2Z0Rps1
nsCSSFrameConstructor::ConstructNonScrollableBlock() has logic to
determine whether to create a block formatting context for a block
frame. I refactor the function to make it reusable by
nsCSSFrameConstructor::ConstructDetailsFrame().
Also, make NS_NewBlockFrame() accept two arguments as other frame
factory functions so that it could be pointed by BlockFrameCreationFunc.
NS_NewBlockFormattingContext is changed accordingly.
The construction for a scrollable DetailsFrame will be further revised
in Part 3.
MozReview-Commit-ID: 8TwG9YMyGva
After using enum class, a switch-case warning in CombineBreakType is caught.
This is one of such kind safty checks that we would like to gain.
Fix it by adding default case for switch-case in CombineBreakType.
MozReview-Commit-ID: BdS3LPN6qzX
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
Drop the aPresContext and aBlockFrame params from RenumberListsInBlock
and rename it RenumberChildFrames. Use 'this' instead of aBlockFrame.
Rename RenumberListsFor to RenumberFrameAndDescendants.
The modification to nsAbsoluteContainingBlock.h and nsBlockFrame.cpp are
needed to fix the build error due to the file order changed in the unified
build.
The #includes are fixed by the following script:
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "nsHTMLReflowMetrics\.h" "mozilla\/ReflowOutput\.h"
MozReview-Commit-ID: KWvcG3UtKNn
