In the existing code, the parent having NS_FRAME_IS_DIRTY is not
propagated to column groups because nsTableFrame::ReflowColGroups checks
the child dirty bit before constructing the reflow state for the child.
This preserves that behavior in the presence of the primary patch in bug
1308876.
I noticed this while debugging the assertion count failure of
layout/base/crashtests/470851-1.xhtml . It doesn't help that failure,
but it still seems like the safe thing to do.
MozReview-Commit-ID: EhfIQQkeaJx
This is the primary patch in this bug, and makes the performance
improvement that fixes this bug.
The assertion count increase for layout/generic/crashtests/1015844.html
is accompanied by a layout change in the testcase as well. However, I'm
not planning to fix it in this sequence; fundamentally columnsets with
specified heights inside a paginated context (like another columnset) do
not work in any reasonable way, and changing the number of times we
reflow them can change the layout. At least, assuming I didn't lose
something in the process of simplifying the testcase.
ISSUES:
- may make block inside XUL worse in performance by marking dirty more (see subdoc in Firefox UI, or text control innards?)
MozReview-Commit-ID: GdOvPynqcFP
This change does the following:
* Introduce a new smart pointer called CounterStylePtr which either
holds an AnonymousCounterStyle strongly, or a named CounterStyle
managed by CounterStyleManager weakly, and use it to replace all
RefPtr<CounterStyle> around the codebase.
* Rename CounterStyleManager::mCacheTable to mStyles to reflect the
fact that it is used to manage all styles, not just for caching.
* Add a retired styles list which collect all named CounterStyle
evicted from mStyles, and post a PostRefreshObserver to destroy
objects in that list after next flush.
* Remove helper functions for counter style in nsStyleList and expose
mCounterStyle directly, to make code simpler with the new pointer.
Reason for adding a new smart pointer type rather than making their
AddRef/Release behave like BuiltinCounterStyle is that, it is possible
that after a flush, some stale style structs may still be alive. They
can contain pointer to destroyed CounterStyle objects. Although the
actual content may never be accessed anymore, RefPtr may still access
the object for refcounting during destruction.
MozReview-Commit-ID: xxegwSDhNb
That function has a special path for when there's no parent reflow input, and if
there's a parent reflow input there should always be a parent frame.
MozReview-Commit-ID: EYh0aE4ozBg
Per bug 1322570 comment 46, it's not easy to replace ComputedJustifyItems()
and UsedJustifySelf()'s internal nsStyleContext::GetParent() without
correctness penalty, so we use GetParentAllowServo() for now.
Also, fix the reftest.list added in bug 1334403 which incorrectly wrote test
page as reference page.
MozReview-Commit-ID: 6kAAWSFojd5
Per bug 775624 comment 95, the method modifies only nsReflowStatus, and is
lived in ReflowInput only because nsReflowStatus was an uint32_t. So it's
better to move it into nsReflowStatus.
MozReview-Commit-ID: DSY2u9az67A
This patch is written with the help of 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 "css::Side" "Side"
MozReview-Commit-ID: DPV6vivpPUp
(We don't want to disregard this position -- it's what we use to encode the
start of the alignment container for this child, when we're doing CSS Box
Alignment. So we need it to be reflected in the hypothetical position, not
disregarded.)
MozReview-Commit-ID: 28IgPn8z1Hr
Previously, I'd thought the "mStaticPosIsCBOrigin" flag was going to become
obsolete -- but now I've realized it's quite useful to avert mixup between the
coordinate space of the grid vs. the coordinate space of
grid-areas-acting-as-abspos-containing-blocks.
So, this patch clarifies/removes some stale comments about this flag, and also
pulls out some code that was unnecessarily in an "else" clause, so that it
happens regardless of whether this flag is set.
(Note: the InitAbsoluteConstraints changes are basically just code-reordering & deindentation.)
MozReview-Commit-ID: 9TFrOuldVBe
