Content under container-type: inline disappears.

[haltesh]

Describe the bug

Some background: in the last year, we've migrated a large portion of our front-end code from Aurelia to Svelte. After doing so, some of our tests suddenly started failing, always in cases where we were using container queries.

I am fully aware that this is most likely a chromium bug, not a svelte bug. But since another framework with the same code does not trigger it, while svelte does, I believe it has something to do with how svelte specifically updates the DOM. Also, while the issues has been reported in the chromium bugtracker, it has so far been largely ignored (https://issues.chromium.org/issues/497855657).

Esentially, in certain situations, whenever the DOM changes under an element with container-type: inline-size, content that should be visible behaves as if it had display: none applied.

Reproduction

https://svelte.dev/playground/6283d99936134b888bfa731069cb3c25?version=5.55.1

The issue is a little finicky, changing any of the conditions from a $derived value on the view-model to a local $state variable makes it go away, so the above example is as minimal reproduction as I could make from our production code.

To reproduce:

1. Make sure the results pane is around 1000px wide.
2. Toggle the checkbox off, and then back on.

The table header should be unconditionally visible; yet when you toggle the checkbox back on, it disappears.

Logs

System Info

System:
    OS: Windows 11 10.0.26200
    CPU: (20) x64 13th Gen Intel(R) Core(TM) i7-13700H
    Memory: 13.33 GB / 31.68 GB
  Binaries:
    Node: 24.15.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.12.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 151.0.7922.170
    Edge: Chromium (151.0.4129.86)
    Firefox: 155.0 - C:\Program Files\Mozilla Firefox\firefox.exe
    Internet Explorer: 11.0.26100.8115
  npmPackages:
    svelte: 5.55.5 => 5.55.5

Severity

annoyance

[dummdidumm]

Could you check if #18680 fixes it? You can install a preview build from the PR (see here #18680 (comment)). It's likely not a full fix because there can still be situations where you get the "slow" path which could also have this bug, but ultimately Chrome needs to fix it.