(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
It's only used to know whether we may potentially need to sync-style the
subtree.
Given with these patches we guarantee that when inserting sync, we have the
style tree up-to-date, we can just check aInsertionKind for the same effect.
MozReview-Commit-ID: ADvcjkGq5hi
The main purpose of this change is avoiding doing frame construction when the
style tree is not up-to-date.
In the test-case above, for example, a MathML element is changed, and we
schedule style invalidation for it, but another MathML element is inserted, and
we reconstruct the whole thing, using the out-to-date styles from the MathML
element.
There are other cases where this is more problematic than "we just happened to
use out-of-date styles, and we'll restyle eventually", which is when this
reconstruct happens to hit an element which was recently inserted but happened
to lazily construct.
In that case, we haven't even performed initial styling on the element, so we
just panic and crash.
After this the only sync frame construction case remaining when the style tree
is not setup is CharacterDataChanged, which I'll address in bug 1397091.
MozReview-Commit-ID: FSI2Zb34SaZ
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
