Why does upgrade-an-element queue attribute, connected reactions before exiting early?

[dominiccooney]

Upgrade an element steps 1-2 queue reactions before checking whether the element is custom. AFAIK the step 3 "already custom" check is designed to prevent double upgrade in the case and element is reinserted while upgrade is pending.

Does this mean that there's no "double upgrade" but there is "double attribute changed dispatch" and "double connected?"

For what it is worth, "classic" custom elements fixed this using the queues themselves. It basically made a distinction between the state where upgrade has been queued, but not started; and upgrade had started. Blink implemented this by actually looking at a combination of the element state and whether the element queue's first reaction was upgrade, IIRC, and that seemed to work well.

/cc @domenic

[domenic]

My initial impression is that this is accidental. I'll try to take a look at the best solution, whether it be just rearranging the steps or implementing something more complex like the solution you describe. It might take a day or two due to BlinkOn though.

[kojiishi]

FYI, double-queueing upgrade reactions could also happen in fragment parser. Create an element enqueues upgrade reactions for fragment parser where sync flag is unset. Then inserting the node tries to upgrade before the upgrade is invoked, which enqueues again.

We found innerHTML setter test case hits this.