Improper ordering of the ready events in v2 in some scenarios

[justincy]

Description

Element's ready callback is called after the parent elements ready callback when the parent is rendered in another element's light dom and there is a binding between the parent it's containing element. I think.

Live Demo

http://jsbin.com/komavinoza/edit?html,console,output

Steps to Reproduce

I've done my best to narrow it down in the linked JS Bin. There's a lot required for the setup. I'll do my best to explain:

There are three elements: parent-element --> child-element --> grandchild-element. The child is rendered inside a dom-repeat and a property rendered by the child is bound to the parent. The child renders the grandchild element in it's local dom.

Rendering the child in the parent's local dom, removing the rendering of the property in the child, or removing the binding between the child and the parent will solve the problem.

Expected Results

The ready event of grandchild-element is fired before the ready event of child-element.

Actual Results

The ready event of child-element is fired before the ready event of grandchild-element.

Browsers Affected

• Chrome
• Firefox
• Edge
• Safari 9
• Safari 8
• IE 11

Versions

• Polymer: v2.0.0-rc.3

Polymer v1.x does not exhibit this issue.

[dfreedm]

Fixed 404s: http://jsbin.com/qukifaw/edit?html,console,output
Polymer v1: http://jsbin.com/voquhek/edit?html,console,output

It looks like the 1.x order was also a little bizarre, but I'm not sure if that matters.

[sorvell]

Can confirm this issue. Currently we rely on the ordering of the connectedCallback to maintain the guarantee that client dom "readies" before a host. Because templatized content flushes before being inserted into the document, client dom is not connected at this time and therefore does not flush/ready.

To address this, we could avoid flushing template instances until their content has been inserted into dom. This makes the usage of templatize a bit tricky so we may want to consider a different fix.