stylo: use invalidation framework to handle restyles needed in response to content insertion/removal

Assigned to



2 years ago
5 months ago


(Reporter: heycam, Assigned: emilio, NeedInfo)


(Blocks 3 bugs)

Dependency tree / graph

Firefox Tracking Flags

(firefox57 wontfix)


(Whiteboard: [qf:p2:responsiveness])



2 years ago
Currently we respond to content modifications needing to restyle elements due to slow selector flags by posting restyles.  For example, when we append a new element to a parent that is marked as having a child that needs :last-child matched, we'll post an eRestyle_Subtree on the old last child.  It seems like we should be able to use invalidations to do more targeted restyling.
Yes, indeed! I thought about this before, and this would allow us to avoid the selector_flags_map, and the flags_setter, which is nice.


2 years ago
See Also: → 1407022


a year ago
See Also: → 1443066
So I thought a bit more about how to do this, and of course it's not an easy fix, but it's not impossible either.

The problem is that we can't invalidate style synchronously during the DOM mutation, because that can get out of sync with class changes and what not.

So the proper way to fix this, I think, is to teach the snapshot stuff about positional pseudo-classes. For that, we could make the snapshots have an "old next / prev" sibling, that would allow us to reconstruct the old sibling chain.

So it'd be something like, for positional pseudo-classes, snapshot the prev and next siblings on DOM insertion / removal. Then the invalidation machinery would take over and invalidate other stuff if needed as it does for attribute changes.

For :empty / :-moz-only-whitespace it's a bit more annoying, because we need to snapshot the parent, but I think it's not much harder than that / making the snapshot aware of whether it was empty.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> For :empty / :-moz-only-whitespace it's a bit more annoying, because we need
> to snapshot the parent, but I think it's not much harder than that.

Hmm, well, it might, because we'd need to compute accurately whether :empty / :-moz-only-whitespace have changed...
I think the only way to fix this in a sane way is either snapshotting previous parent / siblings of the DOM element, or just ditching the "invalidate during the traversal" stuff and do it sync. But that's kind of a pity.
Blocks: layout-perf

Comment 5

11 months ago
A somewhat mixed alternative would be to collect the invalidations sync, and invalidate during the traversal... That may be a good trade-off I guess.

Comment 6

10 months ago
I have better ideas I think...

Comment 7

10 months ago is the try run. is the talos push.

I didn't remove the selector flags setters and stuff but I should... I left them just in case they were needed to make stuff faster, though so far talos hasn't showed anything ridiculous.

This should fix bug 1480477 & co. There's a bunch of tricky invalidation test-cases I want to land.

Also I think I haven't handled :empty invalidation yet, but that should be trivial compared to :nth-child & co.
Assignee: nobody → emilio
Blocks: 1480477

Comment 8

10 months ago
Also, some more cleanup can be done too afterwards.

Comment 10

10 months ago
Looks like I have some perf work to do if I really want to get rid of the slow selector flags... Stylebench isn't happy about this:


10 months ago
Depends on: 1481155


10 months ago
Depends on: 1481156


10 months ago
Depends on: 1481162

Comment 11

9 months ago
Boris, friendly ping regarding your feedback on the style invalidation? Let me know if you don't have cycles to look into it and I'll just write patches :P
Flags: needinfo?(bzbarsky)

Comment 12

9 months ago
(Adjusting priority since it blocks bug 1480477)
Priority: P4 → P2
Sorry, I've been on unexpected PTO most of this week...  I won't really be back to work until Tuesday morning.  I will definitely try to look at this then.
Whiteboard: [qf:p1:f64]

--> retriaging as [qf:p2:responsiveness] since qf:p1 is now reserved for pageload, and it sounds like this bug is mostly about reacting to dynamic changes.

Whiteboard: [qf:p1:f64] → [qf:p2:responsiveness]
You need to log in before you can comment on or make changes to this bug.