Hydration crashes in if branch for undefined data

[kkarikos]

Describe the bug

Hydration can crash at

svelte/packages/svelte/src/internal/client/dom/blocks/if.js

Line 65 in 018996c

hydrate_index = parseInt(data.substring(1));

because data is undefined.

When browser extension (or browser itself in some cases*) modifies the DOM content before the hydration executes, the value of data can become undefined. The result is that the whole page disappears which is unacceptable. Adding a check for undefined here fixes the issue but I am not certain what would be the desired value in this case.

*Safari WebView for example can detect some content as being telephone number and will modify it to become a link.

Reproduction

I created simple browser extension to modify #results of my application.

// manifest.json

{
  "manifest_version": 3,
  "name": "Localhost DOM Modifier",
  "version": "1.0",
  "description": "Modifies DOM for pages running on localhost",
  "permissions": ["activeTab", "scripting"],
  "host_permissions": ["http://localhost/*"],
  "content_scripts": [
    {
      "matches": ["http://localhost/*"],
      "js": ["content.js"],
      "run_at": "document_start"
    }
  ]
}

// content.js

window.addEventListener("load", function () {
  // Get #results container and add a test message as first child
  const resultsContainer = document.getElementById("results");
  const testMessage = document.createElement("div");
  testMessage.textContent = "TEST: This is a test message";
  resultsContainer.insertBefore(testMessage, resultsContainer.firstChild);
});

Logs

System Info

Binaries:
    Node: 20.17.0
    npm: 11.2.0
    pnpm: 9.11.0
  Browsers:
    Brave Browser: 135.1.77.100
    Chrome: 135.0.7049.95
  npmPackages:
    svelte: 5.28.2 => 5.28.

Severity

blocking all usage of svelte

[kkarikos]

I was looking few solutions and seems that just returning from the function in case the data is undefined fixes the issue.

...
if (data === undefined) {
  return;
}
hydrate_index = parseInt(data.substring(1));
...

I can do a PR but I am afraid I do not have the full understanding of the consequences this has. Anyways happy to help if possible as this is causing lot of headache for us in production at the moment.

edit: The "fixes the issue" is maybe bit of overstatement - the application does not crash but it removes the content that got injected by an extension. Ideally that would be left alone.

[jjones315]

Seeing this in Chrome 135.0.7049.115 too

[mado-opus]

I experience this error on Firefox137.0.1 and Chromium 135.0.7049.84, so I don't think it's a browser specific issue.

[kkarikos]

From what I can tell it is not browser specific. What I meant about Safari WebView in the initial report was that this does not only occur with extensions injecting things into DOM - also browsers do that in some cases.

[mado-opus]

Thanks, kkarikos!
I was though especially referring to the fact that @dummdidumm added the "browser specific" label to this issue.

[Rich-Harris]

Can anyone create a simple reproduction of this issue? By 'simple' I mean a component plus some malformed HTML, not a browser extension — it needs to be something that can go into our test suite

[7nik]

Example1, Example2

[Rich-Harris]

closed via #15851