registration order shouldn't matter as much

[sigmundch]

Consider for example event_path_declaration_test.dart. If we swap the registration order of x-foo and x-bar we see additional unexpected calls to ready();

We need to investigate - this might be a problem in polymer.js as well.

[jmesserly]

errr, registration order does matter :). Whoever gets upgraded first will see other elements un-upgraded.

I don't know if that's the problem in the tests, or are you seeing something else?

This might be a fatal flaw in our @­CustomTag :|

[blois]

If no Polymer elements are expanded until all registrations have completed then the contract of all children being accessible when Polymer.ready is called will continue.

[jmesserly]

yeah, I think in this case it's an issue with the <template> content, not with super/subclasses.

[sigmundch]

The problem here is that we are getting multiple calls to ready() and created() for the same instance of a custom element.

So far I've only been able to trigger this with custom-events and <content> propagation.

I've attached a code sample that reproduces the problem. I was able to reproduce this without my partial changes to polymer events, btw.

---

Attachment:
a.html (1.08 KB)

[sigmundch]

err - the error doesn't repro without my changes in polymer-events, however, blink shouldn't do the 2 created calls regardless.

[sigmundch]

Set owner to @sigmundch.
Added Accepted label.

[sigmundch]

Ok - the issue with duplicate 'ready' calls seems gone now in polymer 0.8.8.

---

Removed this from the Later milestone.
Added this to the M8 milestone.
Added CannotReproduce label.

[sigmundch]

I managed to repro this problem again with event_path_declaration_test. I'll keep investigating.

---

Added Triaged label.

[sigmundch]

So it seems this is related to the GC issue Pete discovered.

Attached is an updated version that forces GC to trigger the issue.

Seems that we create the new wrapper as we walk up with 'parentNode' from the event target.

---

Attachment:
a.html (1.16 KB)

[sigmundch]

What really seems strange to me is that saving a reference to the existing node doesn't help. Try attached version instead.

---

Attachment:
a.html (1.19 KB)

[sigmundch]

Removed this from the M8 milestone.
Added this to the Later milestone.

[sigmundch]

Removed this from the Later milestone.
Added this to the M9 milestone.

[clayberg]

Removed this from the M9 milestone.
Added this to the 1.1 milestone.

[sigmundch]

Removed this from the 1.1 milestone.
Added this to the 1.2 milestone.

[sigmundch]

Added AssumedStale label.