solidjs / solid / 34311775365

71%

main: 89%

push

github

fix(web): read a spread's children once in ssrElement (#3313)

b64071c3 (#3287, textarea spread values as content) lifted the loop's
`const value = props[prop]` above the ChildProperties early-out so the new
textarea branch could use it. On a spread those reads are compiled getters:
`children` builds the child element and consumes hydration ids as it goes.
The lift made it run twice when self-closing (`<a {...props} />`) and once
when JSX children already own the slot (previously never). Each stray run
burned an id the client never allocates, so every element after the first
such spread hydrated against the wrong node and the client halted with
"Cannot read properties of null (reading 'nextSibling')". rc.6 was clean
with the same compiler.

Reverse the lift: the textarea branch reads its own value, the general read
returns to below the two early-outs, and the loop now documents why the
order is load-bearing.

Specs pin the contract rather than the symptom: a wrapper spreading
`children` keeps every _hk contiguous (the regression produced 0,1,3,4,6,7,9);
the children getter fires once when self-closing and zero times with JSX
children; every other spread key fires exactly once; textarea value in a
spread still renders as content and is read once (#3286 preserved). The
existing sibling-spread specs never reached this path because JSX children
make ssrElement skip the spread's children entirely.

Closes #3313

Co-authored-by: Cursor <cursoragent@cursor.com>

516 of 784 branches covered (65.82%)

Branch coverage included in aggregate %.

768 of 1002 relevant lines covered (76.65%)

14.99 hits per line