(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
nsReflowStatus::IsEmpty() assertions are added after DISPLAY_REFLOW in the
beginning of the Reflow().
A few Reflow() implementations have Reset() calls at the end which are left
in place by this patch (with an explanatory comment added to each). These
ending Reset()s are only needed for cases where a non-splittable frame
passes its own nsReflowStatus to a child's reflow method. Just in case the
child leaves a "not fully complete" value in the nsReflowStatus, the
non-splittable parent frame must clear out the nsReflowStatus before
returning, so that its own parent doesn't then try to split it.
MozReview-Commit-ID: 6Jj3jfMAqj4
It's good to save a copy constructor call.
Also, make nsBlockFrame::SplitFloat() return void because the only
caller (BlockReflowInput::FlowAndPlaceFloat()) doesn't check its return
value, and (more importantly) because it only ever returns NS_OK.
MozReview-Commit-ID: 9LmDCXd7xGS
This fires, for example, in layout/base/crashtests/265973-1.html (and a
number of other tests, I believe) with the primary patch in this bug.
This is because the primary patch causes frames to be dirty less often,
which sends us into the PrepareResizeReflow codepath, which only happens
when frames are not dirty.
I don't think NS_CoordSaturatingAdd is needed here, since newAvailISize
is used only when deciding whether or not lines need reflow; wraparound
should only cause us to do a little extra work.
Note: This patch passes try on its own, on Linux64 debug.
MozReview-Commit-ID: K6Z5MvG7awp
The primary patch in this bug causes fewer dirty reflows, which leads to lines
being out-of-date for the reason described in the comment. This causes
incorrect layout of some references sections on wikipedia, for which a
simplified testcase is included.
This bug was not caught by anything in our test suite, but I noticed it
while browsing wikipedia (since I use a build that has my patches in it
for my regular browsing).
MozReview-Commit-ID: 4hTQpGS2pZH
Both of the changes are needed to fix
layout/reftests/w3c-css/submitted/css21/pagination/moz-css21-float-page-break-inside-avoid-4.html
with the primary patch in bug 1308876.
That patch changes the transfer of NS_FRAME_IS_DIRTY from parent to
child so that it happens at the start of the parent's reflow rather than
later at the start of the child's reflow, which means that frames that
are pulled into a dirty frame during reflow are not marked dirty (and
thus forced to reflow all of their lines). This means that the primary
patch in bug 1308876 introduces the possibility of non-dirty reflows
during printing, which means we exercise non-dirty relayout code in a
number of tests where we did not do so previously.
Note: This patch passes try on its own, on Linux64 debug.
Writing a simple test for this that fails without the primary patch in
bug 1308876 seems difficult. ColumnSetFrame responds to
nsReflowStatus::NextInFlowNeedsReflow by marking the next-in-flow
*dirty* (which page frames don't), which makes it hard to test in
columns, at least without nesting. (Colums probably shouldn't do that,
though, but that's a performance fix for another time.)
MozReview-Commit-ID: JZ3qWTSO2lX
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
