Pointer-event style on body not reset right with svelte 5.35.4 to latest (5.36.13)

[charlie-roosen]

Describe the bug

Starting with svelte 5.35.4, there is a problem when a dialog is launched from a menu item. This is still present in the latest svelte as of 5.36.13.

When the dialog is dismissed the style attribute on the body should be cleared. Instead it still contains "pointer-events: none;" which blocks UI interaction with the mouse.

This is with bits-ui 2.8.11 using shadcn-svelte.

The problem does not occur when the dialog is launched from a button. Only from a menu item.

The svelte 5.35.4 release includes one change #16280 titled:

"fix: abort and reschedule effect processing after state change in user effect"

https://github.com/sveltejs/svelte/releases/tag/svelte%405.35.4
sveltejs/svelte#16280
https://github.com/sveltejs/svelte/pull/16280/files/8d823390f92f0ad27527445620884ae7ad5769ae

I suspect the rescheduling of effect processing causes a change in behavior of the bits-ui code in "use-floating.svelte.ts". It has a series of effects:

$effect(update); $effect(attach); $effect(reset); $effect(() => cleanup);

So maybe the timing of resetting the body style by the menu on close and the dialog on open is getting done in the wrong order.

Looking at the element in the browser dev tools when the problem occurs, the pointer-events attribute in the style changes as follows:

a) Initial page launch: not set
b) Menu opened: pointer-events: none:
c) Dialog opened: not set
d) Dialog closed: pointer-events: none:

The expected pointer-events value as observed with svelte 5.35.3 is:

a) Initial page launch: not set
b) Menu opened: pointer-events: none:
c) Dialog opened: pointer-events: none:
d) Dialog closed: not set

Please let me know if you can reproduce this, e.g. have a test case on hand of launching a dialog from a menu. If not, I can try to create a Stackblitz.

Reproduction

TODO

Logs

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (12) x64 12th Gen Intel(R) Core(TM) i7-1265U
    Memory: 11.39 GB / 31.69 GB
  Binaries:
    Node: 22.4.1 - C:\Program Files\nodejs\node.EXE
    npm: 10.9.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (138.0.3351.65)
    Internet Explorer: 11.0.26100.1882

Severity

blocking an upgrade

[azvyae]

Can confirm it, and pretty annoying, especially when updating state when the dialog is open, or binding the open attribute of the dialog programatically

[charlie-roosen]

I figured out this one was my fault. Apologies for any inconvenience. I guess this shows why I should create a simpler reproduce before reporting.

I have a component that wraps a component that has the <Dialog.Root> etc. I pass down the "open" and "onOpenChange" properties.

In the component, I had an "{#if opened}<BaseDialog ...>{/if}".

That is, the life of the component being used was dependent on the value of the "opened" boolean. This must interfere with the timing of the cleanup activity around resetting the style on the body.

I removed the "{#if opened}" and rebuilt with the latest bits-ui and svelte, and things are working right. So I'll go ahead and close this.