Created attachment 272392 [details] Test case When a shadow host's focus state changes and outline is drawn, slots' assigned contents show up at the bottom of the shadow DOM. See the attached test case.
Antti, is RenderTreePosition's next sibling supposed to refer to a render node after a slot when we're at a node assigned to the slot? There appears to be a serious inconsistency in the way TreeResolver and RenderTreePosition traverse the composed tree.
<rdar://problem/24873102>
More specifically, when TreeResolver::createRenderer is called on an assigned element, renderTreePosition's m_nextSibling is null so we end up inserting to the end of the shadow root. Either RenderTreePosition's nextSiblingRenderer or ComposedTreeIterator ought to find the render object after the slot to which the element is assigned. This could be recursive because the slot (A) can then be assigned to another slot (B) when (A)'s parent has a shadow root that contains (B).
It looks like this is fixed now :D We just need to land a test.
Created attachment 278408 [details] Add a test
Comment on attachment 278408 [details] Add a test Clearing flags on attachment: 278408 Committed r200581: <http://trac.webkit.org/changeset/200581>
All reviewed patches have been landed. Closing bug.