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
1.Remove NOISY_FIRST_LINE, NOISY_MAX_ELEMENT_SIZE, NOISY_MAXIMUM_WIDTH.
2.Remove REALLY_NOISY_FIRST_LINE.
Only one static function, which has no caller, but defined under this flag.
3.Move REALLY_NOISY_REFLOW_CHILD into REALLY_NOISY_REFLOW.
The chunk of REALLY_NOISY_REFLOW_CHILD seems dead for long time, so make it
alive by moving it under REALLY_NOISY_REFLOW.
MozReview-Commit-ID: E7IW0qStdck
Per html spec, the disclosure triangle can be generated via "display:
list-item", I removed the code to generate the triangle in
SummaryFrame::SetInitialChildList(). That is, when a web page set
"display: block" to the summary, the triangle will disappear, too.
Now SummaryFrame does nothing and is going to be removed in Part 2.
Also summary element should not increment the counter as hinted as
"counter-increment: list-item 0" in the spec. Hence the change in
nsBlockFrame::RenumberListsFor().
The rendering hint in html spec:
https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements
MozReview-Commit-ID: DELGYFe3zGX
What's happening here is that we enter an infinite loop by oscillating
between two states. The code assumes that (a) the available space will
never grow, only stay the same or shrink, and (b) that we should break
out of the loop if it stays the same. This also means we hit the
assertion about the available space growing every other time through the
loop.
This is in the inner loop in nsBlockFrame::ReflowBlockFrame that was
introduced in https://hg.mozilla.org/mozilla-central/rev/80ef9bb2c2e9 .
The problem is fundamentally a logic error in that code. The makes the
assumption that if you reduce the width available to a block formatting
context or replaced block-level element, its height does not shrink.
(The "replaced block" (really block formatting context) in this case, as
in the original testcase, is a scroll frame. I didn't debug the
original testcase enough to figure out what caused its sizing
characteristics, although a percentage-width image does seem like the
most likely candidate.)
Without the patch, the reftest test (but not reference) hangs, as does
the semi-simplified test in the bug (given a narrow window).
With the patch, neither the semi-simplified test in the bug nor the
reference hangs, and the reftest passes.
Note that nsMathMLContainerFrame and its subclasses are unchanged since
they are not target of fullscreen (and thus no backdrop frame), and they
have an assertion to ensure we really don't pass any unexpected list in.
AutoTextRun now only needs a DrawTarget instead of an nsRenderingContext, and
similar nsRenderingContext/gfxContext-to-DrawTarget replacements can be
propagated a long way up the call graph. This patch replaces 93 occurrences of
nsRenderingContext and 135 occurrences of gfxContext with DrawTarget; that's
13% of them.
The patch is mostly plumbing changes. A couple of not-entirely-plumbing
changes:
- It adds a comment about the null check in
gfxGlyphExtents::GetTightGlyphExtentsAppUnits().
- A couple of functions simply had an unused gfxContext or nsRenderingContext
parameter removed, e.g. SetLineBreaks().
