Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elements that are upgrading have no CE definition when callback reactions are enqueued #2876

Closed
cbrewster opened this issue Jul 31, 2017 · 1 comment · Fixed by #3124

Comments

@cbrewster
Copy link

commented Jul 31, 2017

https://dom.spec.whatwg.org/#concept-element-custom-element-definition states that every element has an associated custom element definition.

This issue appears when an element is being upgraded. Before the upgrade it will not have an associated custom element definition (it is null).

When a new custom element is defined with the name of this element, the upgrade steps will run.
https://html.spec.whatwg.org/multipage/#upgrades
During the upgrade, steps 3 and 4 enqueue a callback reaction.

https://html.spec.whatwg.org/multipage/custom-elements.html#enqueue-a-custom-element-callback-reaction step 1 requires getting the element's custom element definition. At this point in time the element's custom element definition will be null; therefore, the callback reactions cannot be enqueued.

Step 9 of https://html.spec.whatwg.org/multipage/#upgrades is where the element's custom element definition is actually set.

@dominiccooney

This comment has been minimized.

Copy link

commented Sep 14, 2017

I think it makes sense to talk about enqueuing a reaction as entering a triple of (element, definition, which ∈ { upgrade, connected, … }, extra stuff) with the observation that for a given element you'll only ever see one definition. Because the queues are per-element, the element is implied, but as @cbrewster points out the element's definition isn't set.

The way WebKit has it (for example, here); the element is associated with its queue, and the queue with a definition. Blink and Gecko do it equivalently but structurally differently where reactions hold onto a definition (Blink, Gecko)

The most important thing here is not messing up the timing of when selectors apply differently and what happens on failure.

domenic added a commit that referenced this issue Oct 13, 2017
Fix ordering of custom element upgrade steps
This fixes #2876, ensuring that a custom element definition is always
present when we enqueue a reaction.
domenic added a commit that referenced this issue Oct 16, 2017
Fix ordering of custom element upgrade steps
This fixes #2876, ensuring that a custom element definition is always
present when we enqueue a reaction.
alice added a commit to alice/html that referenced this issue Jan 8, 2019
Fix ordering of custom element upgrade steps
This fixes whatwg#2876, ensuring that a custom element definition is always
present when we enqueue a reaction.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.