[Socialpranker]

Closes #18447.

<select> accepted no defaultValue, so the only way to say which option starts selected was to put selected on the matching <option>. That falls apart when the options come from an #each, and it's impossible when the element is spread from an object, which is what the linked SvelteKit issue about resetting remote forms runs into.

Writing it didn't error, it just did nothing. is_dom_property() counts defaultValue as a property, so the client compiled <select defaultValue="b"> down to select.defaultValue = 'b', and HTMLSelectElement has no such property. The server dropped the attribute on the floor.

The fix marks the matching option selected, since that attribute is the default state the form reset algorithm restores. Two details were needed to make it behave. The call has to be emitted after the children, otherwise it runs before the options have their values assigned and matches nothing. And the current selection is only restored afterwards when something actually asked for an option through value or bind:value; without that check the initial default never took effect, because restoring selectedIndex put the browser's implicit "first option" choice back.

Server-side select_value now falls back to defaultValue when there's no value, so SSR emits the same selected attribute the client produces and hydration agrees.

An explicit value still wins over defaultValue while the form is live, and resetting the form goes back to the default, matching how <input defaultValue> already behaves.

Added tests/runtime-runes/samples/form-default-value-select, which covers the three cases and a form reset. It fails on main and passes here. Ran the full suite (7546 passing) plus tsc and eslint. The runtime-browser file fails on my machine because the Playwright browser isn't installed, and it fails the same way on a clean checkout of main.

Written with Claude Code (Claude Opus 5); I reviewed and tested everything before submitting.

[pkg-svelte-dev]

Install the latest version of svelte from 1536096:

pnpm add https://pkg.svelte.dev/svelte/c/1536096dae692dff342c1b24b4804aa7d1115c05

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/svelte/pr/18591

Note

This PR is from a fork. A maintainer must approve approve each commit before it can be built and installed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 1536096

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

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

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

[Nic-Polumeyv]

The client transform only applies this when there's no spread (if (!has_spread && name === 'select') in RegularElement.js), and set_attributes has no defaultValue handling for selects, so <select {...props}> compiles to $.attribute_effect(...) and never reaches set_default_select_value. The server renderer does handle the spread case, so SSR and CSR diverge on exactly the usage #18447 was filed for: SvelteKit's <select {...form.fields.x.as('select')}> (sveltejs/kit#16093) is always a spread.

[Socialpranker]

You're right, and it was worse than just the client: the server read the key only as defaultvalue, which is what the compiler emits for an attribute written in the template, but a spread passes keys through as the user wrote them. So SSR ignored it too and the two sides disagreed for a different reason than the one you spotted.

Fixed in 22c07e6. The client now marks the default option from the same effect that already handles value for spreads, once the options exist, and the server accepts both spellings. Added a runtime sample with {...props} and an SSR sample covering both, since my original test only exercised the non-spread path, which is why green CI told me nothing here.

[Socialpranker]

The red Tests (20, windows-latest) on 72eef03 doesn't look related to this PR — it's the same Windows runner flake that hit main itself.

The job dies without running anything. Its log ends on the vitest banner with no test results at all:

> vitest run

 RUN  v4.1.7 D:/a/svelte/svelte

That's the last line — 350 lines of log, zero Test Files / FAIL / assertion output, and the job sat for 4 minutes (11:04→11:08) while every other job in the run finished in 2-3.

The same thing happened on main in run 29288819961 (13 July, no PR involved): Tests (20, windows-latest) failed after 4 minutes (22:08→22:12), log ends on the identical RUN v4.1.7 line, zero test results. 330 lines vs my 350, same shape.

Everything else on this run is green — Ubuntu on Node 20/22/24, macOS, Lint, TSGo, TestNoAsync, Benchmarks.

Locally the new test passes (form-default-value-select-multiple, 2 passed). I can't run the full suite to completion on this machine, so I'm not claiming more than that — but the main failure above is the part that shows this isn't a regression from the commit.

Could someone with the right access re-run that job? I don't have permission to (Must have admin rights to Repository). Happy to push an empty commit instead if that's easier.

[Socialpranker]

Following up here — anything else needed on the flake explanation, or is this just waiting for a re-look?

[Socialpranker]

Correction to my earlier comment: I was wrong about the log. The failing Windows job does produce test output — I read a truncated log and reported it as empty. The actual failure is a single test:

FAIL packages/svelte/tests/signals/test.ts > signals > schedules rerun when writing to signal before reading it (runes mode)
Error: Test timed out in 30000ms.
Tests  1 failed | 7674 passed | 69 skipped (7744)

It's still unrelated to this PR, but for a better reason than the one I gave. The same test times out on main with no PR involved:

• https://github.com/sveltejs/svelte/actions/runs/32419712753 (20 Aug, docs: added generic type parameter example for $state (#18490))
• https://github.com/sveltejs/svelte/actions/runs/29288819961 (13 Jul, chore: bench compare report as HTML (#18543))

Same job, same single test, same 30s timeout. The Windows runner takes ~176s for the suite where the others take 2-3 minutes total, so a 30s per-test timeout is marginal there. Nothing in this PR touches the signals runtime.

A re-run should clear it — I don't have permission to trigger one. Happy to push a merge of main if that's easier for you than a manual re-run.

[Socialpranker]

Thanks for merging main — CI is fully green now, Windows included (Tests (20, windows-latest) passed in 4m3s).

One data point that may be worth more than this PR: I tried to reproduce that timeout locally while you were merging, and it reproduces on clean main with no PR involved — packages/svelte/tests/signals/test.ts -t "schedules rerun when writing to signal before reading it", macOS, isolated run, failed 1 of 3 times at the 30s timeout. On the merged branch it passed 3 of 3. So it isn't Windows-specific, it's just timing-sensitive enough that a loaded runner tips it over, and Windows is the slowest runner in the matrix.

If it keeps costing people re-runs, a larger testTimeout for that file would probably settle it. Happy to open a separate PR for that if you'd like — not folding it into this one.