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

RESOLVED FIXED in Firefox 40

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: heycam, Assigned: heycam)

Tracking

Trunk
mozilla40
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox40 fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

4 years ago
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.
(Assignee)

Comment 1

4 years ago
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.
(Assignee)

Comment 2

4 years ago
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.
(Assignee)

Comment 3

4 years ago
Created attachment 8595779 [details]
makings of a small test case
(Assignee)

Comment 4

4 years ago
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
(Assignee)

Comment 5

4 years ago
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.
(Assignee)

Comment 6

4 years ago
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".
(Assignee)

Comment 7

4 years ago
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.
(Assignee)

Updated

4 years ago
Depends on: 1157150
(Assignee)

Comment 8

4 years ago
Created attachment 8595841 [details] [diff] [review]
patch
Attachment #8595841 - Flags: review?(dbaron)
https://hg.mozilla.org/mozilla-central/rev/cf8187912057
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.