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.
Created attachment 8595799 [details] 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.
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.
Created attachment 8595841 [details] [diff] [review] patch
Attachment #8595841 - Flags: review?(dbaron)
Comment on attachment 8595841 [details] [diff] [review] patch r=dbaron; sorry for the delay
Attachment #8595841 - Flags: review?(dbaron) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in before you can comment on or make changes to this bug.