New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 672732 link

Starred by 2 users

Issue metadata

Status: Duplicate
Owner:
Last visit > 30 days ago
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Custom Element v1 bug

Reported by nicolai...@gmail.com, Dec 9 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36

Steps to reproduce the problem:
Open attached file in browser

What is the expected behavior?
<tag-1>aa<tag-2> TAG2 </tag-2>bb</tag-1>

Must give result:
xx

Because for tag-1:
connectedCallback(){console.log(this.innerHTML); this.innerHTML='xx' }

What went wrong?
If use document.write('<tag-1>aa<tag-2> TAG2 </tag-2>bb</tag-1>')- correct result,

but if put <tag-1>aa<tag-2> TAG2 </tag-2>bb</tag-1>
into Html directly result will be  
'xx TAG2 bb '

In second variant property innerHTML inside connectedCallback contains only data before first occurence of nested custom element. Remainder appended after element will be rendered in any case, even if assign innerHTML empty string.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 55.0.2883.75  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

If use Custom Element v0 - correct result in both cases.
 
a.html
1018 bytes View Download
In opera incorrect in both cases:
1)xxaa TAG2 bb 
2)xx TAG2 bb 

correct:
xx
Components: -Blink>WebComponents Blink>HTML>CustomElements
Labels: M-55
Owner: dominicc@chromium.org
Status: Assigned (was: Unconfirmed)
Hmm, this looks interesting. Thank you for filing this.

In 54.0.2840.100 (Official Build) (64-bit) this does this:

First Variant(correct): document.write('<tag-1>aa<tag-2> TAG2 </tag-2>bb</tag-1>')
xxaa TAG2 bb 

Second Variant(incorrect)- in html: <tag-1>aa<tag-2> TAG2 </tag-2>bb</tag-1>
xx TAG2 bb 

At ToT this behaves differently and does this:

First Variant(correct): document.write('<tag-1>aa<tag-2> TAG2 </tag-2>bb</tag-1>')
xx 

Second Variant(incorrect)- in html: <tag-1>aa<tag-2> TAG2 </tag-2>bb</tag-1>
xx TAG2 bb 

I guess the bad news here is this has changed what you viewed as the correct behavior.

I need to sit down and step through the spec to see what's happening here. It would be interesting to see what Safari does with this, too.
I check in safari technology preview
1) "xx" 
tag1.innerHTML= "aa<tag-2> TAG2 </tag-2>bb"
tag2.parentNode null

2)"xx" 
tag1.innerHTML= "aa<tag-2> TAG2 </tag-2>bb"
tag2.parentNode null

result correct, but there tag2.parentNode is null, must be tag1
At chrome tag2.parentNode is null in first case and tag1 in second. 

I think in v1 custom tags processed somehow separately.

I try to move one framework from v0 to v1, see sample1.txt 
So inside connectedCallback absolutely broken logic between tags. I cant change child content in connectedCallback and get parent data. It can be determined correct only after rendering.    


sample1.txt
920 bytes View Download
I accidentally find out that my framework added  components only dynamically in js, so all work)

Only if custom component statically placed on html page problem occured. 
Problem only with static elements on chome & opera v1 components.

On safari v1, and many other browser with v0 polyfill all correct in both cases. 

I think chrome do some optimization, but this behaviour is very confusing.
Mergedinto: 676365
Status: Duplicate (was: Assigned)
I suspect this may be a dup of Issue 676365. Sorry for the forward dup. After the fix for that issue, both cases result in xx aa TAG2 bb and innerHTML is '' when the connected callback runs. Yay.

Sign in to add a comment