1157097 - patches in bug 989469 cause "ASSERTION: frame still referencing style context" to fire

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Cameron McCormack (:heycam)]

I think this is due to enqueuing a style context to have ClearCachedInheritedStyleDataOnDescendants called on it, but then later in the same restyle returning it from nsStyleContext::FindChildWithRules.

Comment 1

[Cameron McCormack (:heycam)]

And we do that because the style context starts off as non-shared, and thus is not ineligible to have structs swapped from it, and then we append it to mContextsToClear.

Comment 2

[Cameron McCormack (:heycam)]

I have the makings of a small test case, but I'm having trouble getting exactly the right restyle events posted to trigger the bug, and starting from about:addons and minimizing that seems a bit hard right now.  I might end up adding an nsIDOMWindowUtils method that just calls nsLayoutUtils::PostRestyleEvent.

Comment 3

[Cameron McCormack (:heycam)]

Attachment: makings of a small test case

Comment 4

[Cameron McCormack (:heycam)]

Attachment: makings of a small test case v2

This does trigger the assertion, where element.postRestyleEvent() in script just calls nsLayoutUtils::PostRestyleEvent(element, eRestyle_Self, 0).

If there is a way to cause an eRestyle_Self restyle to be posted but with a guarantee that we get back the same style context when we do process the restyle, I could use that instead.

Comment 5

[Cameron McCormack (:heycam)]

This works by:

1. restyling the first <span>, getting a new style context, and appending the old style context to mContextsToClear
2. restyling the first <b> with a change that causes a reframe, which leaves the old style context on the frame, thus keeping the first <span>'s old style context alive
3. restyling the second <span>, and getting for the first <span>'s old style context (and sharing it) -- this is the part we want to avoid

Actually the outer <div> is not needed.

Comment 6

[Cameron McCormack (:heycam)]

The best solution I've come up with so far is, when we append a style context to mContextsToClear, to set a bit on it and all its descendants to say "don't consider me when looking for an existing style context to return from nsStyleContext::FindChildWithRules".

Comment 7

[Cameron McCormack (:heycam)]

I'm not 100% sure that we can just set the bit on the style context with stick in mContextsToClear; that would be enough for this test (and for bug 989469), but I'm not certain that we won't ever resolve a frame's style context to something in that style context's subtree when processing the remainder of the restyles under ProcessOneRestyle.

Comment 8

[Cameron McCormack (:heycam)]

Attachment: patch

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8595841 [details] [diff] [review]
patch

r=dbaron; sorry for the delay

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/cf8187912057

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/cf8187912057