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.

Sign up for GitHub

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

Jump to bottom

"Remove a node from a parent" reaction callback stuff needs to be conditional on the node being connected before the operation #773

Closed
emilio opened this issue Jul 5, 2019 · 3 comments · Fixed by #827
Closed

"Remove a node from a parent" reaction callback stuff needs to be conditional on the node being connected before the operation #773

emilio opened this issue Jul 5, 2019 · 3 comments · Fixed by #827
Labels
good first issue Ideal for someone new to a WHATWG standard or software project

Comments

@emilio
Copy link
Contributor

emilio commented Jul 5, 2019

https://dom.spec.whatwg.org/#concept-node-remove step 14 says:

If node is custom, then enqueue a custom element callback reaction with node, callback name "disconnectedCallback", and an empty argument list.

This is wrong, it should be conditional on the parent node being connected before the removal (or something of that sort spec-wise), otherwise you get too many callbacks when removing a node from a disconnected parent.

See servo/servo#23716.
@emilio
Copy link
Contributor Author

emilio commented Jul 5, 2019

cc @annevk @jdm

@emilio emilio mentioned this issue Jul 5, 2019
Open
@emilio
Copy link
Contributor Author

emilio commented Jul 5, 2019

All browsers (but Servo, I expect), log disconnected only once in this test-case:

<!doctype html>
<div id="custom-element-parent">
  <custom-element></custom-element>
</div>
<script>
customElements.define('custom-element', class extends HTMLElement {
  disconnectedCallback() {
    console.log("disconnected");
  }
});
onload = function() {
  const p = document.getElementById("custom-element-parent");
  p.remove();
  setTimeout(() => p.firstElementChild.remove(), 100);
}
</script>

@annevk annevk added the good first issue Ideal for someone new to a WHATWG standard or software project label Jul 5, 2019
@annevk
Copy link
Member

annevk commented Jul 5, 2019

Blame for this points to when this got added. It seems the fix here would be to create a boolean before this step that stores whether parent is https://dom.spec.whatwg.org/#connected. And then modify this step and the subsequent step for queueing this specific callback to be conditional upon that boolean. I suspect we don't need new tests.

cc @domenic

@pshaughn pshaughn mentioned this issue Feb 1, 2020
Open
@shvaikalesh shvaikalesh mentioned this issue Feb 3, 2020
Merged
annevk pushed a commit that referenced this issue Feb 7, 2020
@shvaikalesh
Avoid enqueuing "disconnectedCallback" on detached custom elements
de29633 
Fixes #773.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
good first issue Ideal for someone new to a WHATWG standard or software project
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Avoid enqueuing "disconnectedCallback" on detached custom elements shvaikalesh/dom
2 participants
@emilio @annevk