Closed Bug 1157097 Opened 9 years ago Closed 9 years ago

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


(Core :: CSS Parsing and Computation, defect)

Not set



Tracking Status
firefox40 --- fixed


(Reporter: heycam, Assigned: heycam)




(2 files, 1 obsolete file)

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.
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.
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.
Attached file makings of a small test case (obsolete) —
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.
Attachment #8595779 - Attachment is obsolete: true
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.
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".
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.
Depends on: 1157150
Attached patch patchSplinter Review
Attachment #8595841 - Flags: review?(dbaron)
Comment on attachment 8595841 [details] [diff] [review]

r=dbaron; sorry for the delay
Attachment #8595841 - Flags: review?(dbaron) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in before you can comment on or make changes to this bug.