[Solid 2 regression] Direct value and checked bindings overwrite pre-hydration user input #3182

Describe the bug

In Solid 2, direct reactive value and checked bindings overwrite live
form state that the user changed before hydration.

The server and client initial values can match exactly, so this is not an
SSR/client rendering mismatch.

For example:

container.innerHTML = '<input _hk="0" value="server">';

const input = container.firstElementChild as HTMLInputElement;

// Simulate the user typing before the client bundle hydrates.
input.value = "user";

hydrate(() => {
  const [value] = createSignal("server");
  return <input value={value()} />;
}, container);

console.log(input.value);
// "server"

The user-entered "user" value is replaced with the initial signal value.

The same happens with checked:

container.innerHTML =
  '<input _hk="0" type="checkbox" checked>';

const input = container.firstElementChild as HTMLInputElement;

// Simulate a user interaction before hydration.
input.checked = false;

hydrate(() => {
  const [checked] = createSignal(true);
  return <input type="checkbox" checked={checked()} />;
}, container);

console.log(input.checked);
// true

Interestingly, an equivalent spread binding preserves the live DOM value:

hydrate(() => {
  const [value] = createSignal("server");
  return <input {...{ value: value() }} />;
}, container);

console.log(input.value);
// "user"

Steps to Reproduce the Bug or Issue

1. Server-render an input with an initial value.
2. Change the live input.value before hydration, simulating user input.
3. Hydrate using a signal whose initial value matches the server.
4. Inspect the input value.

Expected behavior

Initial hydration should preserve the live user-modified value. The first subsequent reactive update should apply the signal value.

Platform

• @solidjs/web: 2.0.0-rc.4
• next: f051db6a
• Native and Babel compiler paths
• jsdom 25

Additional context

This appears to be a Solid 2 regression of #1849. That issue described input being cleared before queued input events could be replayed and was marked fixed in Solid 1.8.

The direct compiler path treats stateful DOM properties as locked and emits a direct property assignment during hydration. The spread path reaches assignProp(), which skips the initial property write for hydrating nodes.

Related but different: #2016 concerns keeping controlled inputs synchronized during later reactive updates. This issue is specifically about preserving browser state created before the initial hydration pass.