fix: ensure custom element attribute/prop changes are in their own context

[trueadm]

Fixes #13848.

When we set custom element attributes/props, we should be doing so without the current effect/reaction active. Otherwise, the custom element lifecycle might attach effects/dependencies to the wrong reaction and all manner of things can incorrectly occur. I tried to create a test for this using our Playwright testing but I couldn't get it to load up multiple custom elements so I gave up.

[changeset-bot]

🦋 Changeset detected

Latest commit: 127d831

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

pnpm add https://pkg.pr.new/svelte@14016

commit: 999f805

[dummdidumm]

Can you give an example of a life cycle method being invoked in a wrong way as a result of a prop change? The related bug only lists the mutation error, which isn't exactly a life cycle method to me.

[trueadm]

@dummdidumm It's the fact that calling these properties on a custom element invokes code that is not in the runtime's context. So if that method or logic reads state or creates an effect it should be treated as needing it's own context, like we do for events.

[dummdidumm]

Can you give a concrete example, ideally one that isn't related to the mutation error? Ideally a code example (just dump a REPL link; custom elements don't work in there but I can copy-paste it out of there to run locally) I can then try to add it to the test suite.

[trueadm]

Sure my-foo.svelte.js:

class MyElem extends HTMLElement {
  static observedAttributes = ["foo"];
  
  attributeChangedCallback() {
    console.log($effect.tracking())
  }
}
  
customElements.define("my-foo", MyElem);

Foo.svelte:

<script>
  let foo = $state('');
</script>

<button onclick={() => foo = '!!!'}>change</button>

<my-foo foo={foo}></my-foo>

[dummdidumm]

(trying to add a test, and trying to see if this is due to flushSync and if yes whether we should fix it somewhere in there instead)

[trueadm]

attributeChangedCallback fires sync, that's the issue here. It's like the Chrome blur bug all over again.

[trueadm]

Thanks for the test @dummdidumm