Bug 160427 - Input elements don't work inside shadow tree
Summary: Input elements don't work inside shadow tree
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: Safari Technology Preview
Hardware: Mac OS X 10.11
: P2 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 148695
  Show dependency treegraph
 
Reported: 2016-08-01 15:19 PDT by Monica Dinculescu
Modified: 2016-09-26 16:48 PDT (History)
9 users (show)

See Also:


Attachments
Shows that the input has a value but the text doesn't render (49.40 KB, image/png)
2016-08-01 15:19 PDT, Monica Dinculescu
no flags Details
patch (10.26 KB, patch)
2016-09-26 14:44 PDT, Antti Koivisto
no flags Details | Formatted Diff | Diff
patch (10.95 KB, patch)
2016-09-26 15:17 PDT, Antti Koivisto
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Monica Dinculescu 2016-08-01 15:19:24 PDT
Created attachment 285045 [details]
Shows that the input has a value but the text doesn't render

If I have a <div><slot></slot></div> inside a shadow root, distributing an <input> in that slot leads to weird rendering issues (see below). Note that if the <slot> is a direct child of the shadow root (i.e. not nested in that <div>) everything is fine.

Repro: http://output.jsbin.com/fuduvi 
1. There are two inputs, one is distributed in a slot, one is a shadow child.
2. Type something in an input. Nothing actually shows up.
3. Inspect the input. It’s got a value. Toggle a style on that input (such as :focus), and the text shows up.
Comment 1 Ryosuke Niwa 2016-08-01 18:01:50 PDT
Wow, it looks like any form of mutations to the style or text is completely ignored inside shadow trees unless we insert or remove a node.
Comment 2 Ryosuke Niwa 2016-08-01 23:14:54 PDT
(In reply to comment #1)
> Wow, it looks like any form of mutations to the style or text is completely
> ignored inside shadow trees unless we insert or remove a node.

I mean inside slots*
Comment 3 Eric 2016-08-03 22:11:08 PDT
Just want to confirm if https://rawgit.com/ebidel/2d2bb0cdec3f2a16cf519dbaa791ce1b/raw/0bfc15abcf835a0b17e2d97df12ea8cde884faa7/fancy-tabs-demo.html is the same issue. Selecting a tab applies a `selected` attribute to the tab and panel content. It looks like the distributed nodes are not seeing a style recalc.

If this is a different but, happy to file a new issue.
Comment 4 Ryosuke Niwa 2016-08-04 12:58:16 PDT
(In reply to comment #3)
> Just want to confirm if
> https://rawgit.com/ebidel/2d2bb0cdec3f2a16cf519dbaa791ce1b/raw/
> 0bfc15abcf835a0b17e2d97df12ea8cde884faa7/fancy-tabs-demo.html is the same
> issue. Selecting a tab applies a `selected` attribute to the tab and panel
> content. It looks like the distributed nodes are not seeing a style recalc.
> 
> If this is a different but, happy to file a new issue.

Yeah, this seems like the same bug.
Comment 5 Ryosuke Niwa 2016-08-04 13:07:27 PDT
I'm so sorry. This is a terrible bug :(

For now, you can work around it by running:

var originalValue = shadowHost.style.display;
shadowHost.style.display = 'none'; // Any value different from the current one would do.
getComputedStyle(shadowHost).color; // Any property would do.
shadowHost.style.display = originalValue;

This would force style recall on the entire shadow tree.
Comment 6 Ryosuke Niwa 2016-08-15 16:13:14 PDT
*** Bug 160866 has been marked as a duplicate of this bug. ***
Comment 7 Ryosuke Niwa 2016-08-15 22:58:29 PDT
*** Bug 160864 has been marked as a duplicate of this bug. ***
Comment 8 Antti Koivisto 2016-09-26 14:44:34 PDT
Created attachment 289874 [details]
patch
Comment 9 Antti Koivisto 2016-09-26 15:17:53 PDT
Created attachment 289880 [details]
patch
Comment 10 Darin Adler 2016-09-26 15:31:45 PDT
Comment on attachment 289880 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=289880&action=review

> Source/WebCore/dom/ComposedTreeIterator.cpp:183
> +    if (m_contextStack.size() == 1) {
> +        ASSERT(context().iterator == context().end);
> +        return;
> +    }

Why do we need this? The loop below is harmless even without this special case.
Comment 11 Antti Koivisto 2016-09-26 16:42:18 PDT
> Why do we need this? The loop below is harmless even without this special
> case.

We don't. Removed the test.
Comment 12 Antti Koivisto 2016-09-26 16:48:37 PDT
https://trac.webkit.org/r206403