Instead, explicitly capture the frame tree state on the only caller that passes
this flag around.
This is somewhat wasteful if we end up reconstructing an ancestor frame, since
we'll capture state for it again. But we do that already in most of the cases
(somewhat inconsistently).
MozReview-Commit-ID: CUJsXaVoIpO
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
We currently use the aFlags argument of ContentRemoved for two purposes:
(1) To determine when a frame is being removed due to its element being removed
from the DOM, so we reframe its now-possibly-no-longer-suppressed
whitespace siblings as needed.
In other cases, our ContentRemoved call will be followed by a
ContentInserted call, which will end up doing AddTextItemIfNeeded() to
generate the relevant textframes if they're necessary.
Since we only need to tell apart the "DOM removal" and "anything else"
cases, we don't need to thread the aFlags argument through all the ways
ContentRemoved can call itself (on an ancestor).
All those cases should just be treated as "not DOM removal". In particular,
even if the original call _was_ for a DOM removal, if we convert it to an
ancestor reframe, which will call ContentInserted on the ancestor as well,
we don't need to do anything with text siblings of the ancestor.
(2) To save the frame tree state from DestroyFramesFor, but the frame tree
state is unconditionally captured on RecreateFramesForContent, so we only
need to care about it in the original ContentRemoved call.
Because of that, we can move that to the callsite, patch incoming for that.
MozReview-Commit-ID: Gy5IhUysBlz
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
It turns out, this is the only case in which we need to do the fixup at all.
And this way we don't have to guess based on first-line styles, which may not
match the frame tree (for example if we have a pending style change that we
haven't processed yet).
There's only one case of sync frame construction from ContentRemoved now, and
it's not on the element being removed, but on the whitespace siblings if needed,
and _only_ when they don't support lazy frame construction.
Basically, this switches all the RecreateFramesForContent calls to use
`aAsyncInsert` (which I changed to an enum class for readability), except when
we're already reframing.
Also, it switches ReframeTextIfNeeded to opt-in into lazy frame construction,
since it's used only when aFlags == CONTENT_REMOVED.
This allows to simplify the DestroyFramesFor API (which I'm happy to rename to
something more meaningful, since now it's something like
DestroyFramesForAndRecreateThemAsync), and do some other consistency cleanups.
A bunch of the ContentRemoved callsites were pretty random at passing
aAsyncInsert, and that was some kind of a mess. This patch ensures consistency,
and makes it impossible to do O(n^2) work when removing DOM nodes, which is
nice.
The underlying reason for this is explained in the description of bug 1377848,
and basically allows us to remove a bunch of Servo hacks on the longer term (a
few of them are going away already, yay!).
MozReview-Commit-ID: 2DrUTxGV8RX
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
It wasn't clear to me whether the existing check for whether we are
under a restyle was sufficient to cover all cases of reconstructing
frames, so this patch makes it more explicit by passing that state
into ContentAppended and ContentRangeInserted.
MozReview-Commit-ID: HjlDCzJv97n
The major change to the Iterator is due to the fact that the end of a
LinkedList is represented by nullptr.
Also delete the type conversion functions which are no longer needed.
MozReview-Commit-ID: 2lYtFW9pSon
