From bug 1330843 comment 18 and onwards. It looks like we sometimes don't correctly inherit styles when display:contents and XBL is involved. Attachment 8844428 [details] has a test (in the form of a reftest) that shows how we incorrectly inherit from the host element at first, but after reframing, correctly inherit from the grandparent (skipping a display:contents element) within the XBL shadow tree.

I started debugging one of the failing sub-tests from display-contents-xbl.xhtml again (#hostL this time), and one issue seems to be that we pass in the wrong parent style context when we restyle the undisplayed node (the <b>). We are in ElementRestyler::RestyleUndisplayedDescendants, and mFrame is the <div>'s frame. We use the that frame's style context as the parent for all of the undisplayed children we find under it. We do find the <b> here, even though conceptually you might think it is an undisplayed child of the <span> generated by the XBL binding. Is the problem here that we just need to compute a correct parent style context for each child (and it is correct to be finding the <b> here in this invocation of RestyleUndisplayedDescendants) -- maybe by using GetFlattenedTreeParent on the undisplayed node? -- or should we really be finding the <b> when we call RestyleUndisplayedDescendants for the <span> instead?

I guess the former -- calling undisplayed->mContent->GetFlattenedTreeParent()->GetPrimaryFrame()->GetStyleContext() or so in ElementRestyler::RestyleUndisplayedNodes -- won't work, since at the time we're calling ElementRestyler::RestyleUndisplayedDescendants for the <div>, we haven't restyled the <span> yet.

Also see some comments in bug 1368113.