Bug 154770 - Focusing a shadow host places the slot content after the shadow DOM content
Summary: Focusing a shadow host places the slot content after the shadow DOM content
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks: 148695
  Show dependency treegraph
 
Reported: 2016-02-26 19:30 PST by Ryosuke Niwa
Modified: 2016-05-09 10:48 PDT (History)
3 users (show)

See Also:


Attachments
Test case (1.10 KB, text/html)
2016-02-26 19:30 PST, Ryosuke Niwa
no flags Details
Add a test (2.76 KB, patch)
2016-05-09 10:32 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 2 Radar WebKit Bug Importer 2016-02-26 21:16:33 PST
<rdar://problem/24873102>
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 5 Ryosuke Niwa 2016-05-09 10:32:06 PDT
Created attachment 278408 [details]
Add 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.