|Summary:||Focusing a shadow host places the slot content after the shadow DOM content|
|Product:||WebKit||Reporter:||Ryosuke Niwa <rniwa>|
|Component:||Layout and Rendering||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||koivisto, simon.fraser, webkit-bug-importer|
|Version:||WebKit Nightly Build|
|Bug Depends on:|
Description Ryosuke Niwa 2016-02-26 19:30:20 PST
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.
Comment 1 Ryosuke Niwa 2016-02-26 21:16:08 PST
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.
Comment 3 Ryosuke Niwa 2016-02-26 21:20:56 PST
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).
Comment 4 Ryosuke Niwa 2016-05-06 19:24:34 PDT
It looks like this is fixed now :D We just need to land a test.
Comment 6 Ryosuke Niwa 2016-05-09 10:48:01 PDT
Comment on attachment 278408 [details] Add a test Clearing flags on attachment: 278408 Committed r200581: <http://trac.webkit.org/changeset/200581>
Comment 7 Ryosuke Niwa 2016-05-09 10:48:06 PDT
All reviewed patches have been landed. Closing bug.