form 字段 `type: 'email'` 经 bare-name 回退落进 SDUI 节点渲染器,`field`(对象)与 `max_length` 一起泄漏到 DOM

[os-support-ai]

Found while implementing #5201 by measuring which render path a non-builtin field type actually takes. Out of that card's scope (input branch only) — recorded, not fixed there.

观察到的现象(已实测,不是推断)

packages/components/src/renderers/form/form.tsx 的字段渲染在没有 field: 命名空间 widget 时回退到 bare-name 解析 ComponentRegistry.get(type)。packages/components/src/renderers/form/input.tsx:89 把 email(以及 password)注册成 ui namespace 的 SDUI 节点渲染器 —— 它们是给顶层 { type: 'email' } 节点用的,不是 field widget。于是一张手写 FormSchema 里的 { name, type: 'email' } 字段,悄悄落进那条 "non-field component reached through the bare-name fallback" 的路径。

实测(渲染内建分支,不调 registerAllFields();dump getAttributeNames()):

ComponentRegistry.get('email') = true ComponentRegistry.get('field:email') = false

type:'email' + max_length: 50
 attrs=["class","id","max_length","field","aria-describedby","aria-invalid","type","value","name"]
 maxlength=null

两件事同时发生:

1. field 泄漏到 DOM。 它是 raw metadata 对象;该路径走 stripRegisteredFieldProps,而那份剥离表刻意保留 field(它是注册 widget 的元数据载体,objectui#3233),但这个组件不是 field widget —— 它把收到的 props 直接摊到元素上,于是 field 变成元素上的一个游离属性。同族口径见 plugin-dashboard: DashboardRenderer's widget grid spreads the whole SDUI node onto its container — 13 non-DOM attributes reach the DOM #4432 / finding(plugin-dashboard): the #3291 toDomProps whitelist stops at packages/fields — SDUI widgets elsewhere still close their DOM leak by hand, if at all #4425(toDomProps 白名单只覆盖到 packages/fields)。
2. max_length 同样泄漏,且没有任何上限(maxlength=null)—— 与 内建 form 分支的 input 字段:legacy max_length 拼法拿不到任何 maxlength 上限,只在 DOM 上留下一个失效属性 #5201、以及回退分支的那张同族卡一致。

需要先判的那一问,不要直接改

这里有两种读法,通向两种架构,所以本单不带修复方案:

• A:属于 DOM-leak 家族 —— bare-name 路径该有自己的 toDomProps 白名单,像 finding(plugin-dashboard): the #3291 toDomProps whitelist stops at packages/fields — SDUI widgets elsewhere still close their DOM leak by hand, if at all #4425 说的那样把守卫推到 packages/fields 之外。范围小,但没解决「一个 form 字段本就不该落进 SDUI 节点渲染器」。
• B:属于 resolution 家族 —— form 字段的 type 解析根本不该 fall back 到 ui namespace 的节点渲染器。那是更正的形状,但会改变 type: 'email' / type: 'password' 字段今天的渲染结果(它们目前确实渲染出一个可用的 input),属于行为改动,需要先定夺。

两者的取舍不能从 #5201 的结论推出来,交 triage。

起点

• packages/components/src/renderers/form/form.tsx —— RegisteredComponent / namespacedWidget 解析,以及其下 non-field 分支
• packages/components/src/renderers/form/input.tsx:89(email)与其后的 password 注册
• 同族:plugin-dashboard: DashboardRenderer's widget grid spreads the whole SDUI node onto its container — 13 non-DOM attributes reach the DOM #4432(已关)、finding(plugin-dashboard): the #3291 toDomProps whitelist stops at packages/fields — SDUI widgets elsewhere still close their DOM leak by hand, if at all #4425(open,toDomProps 白名单覆盖面)

检索记录

search_issues 跑过 email / bare-name fallback / SDUI node renderer / DOM leak 关键词;命中的 open 卡只有 #4425(相关但不同面:它讲 plugin-dashboard 的 SDUI widget),无重复单。

[os-support-ai]

Triage: escalating to the decision inbox — the A/B fork is a product-semantics choice #5201's ruling cannot answer, and B changes today's rendering of built-in type: 'email' / type: 'password' fields. Typed Bug (the DOM leak is real under either reading).

Four-prism:

• Platform coherence — a form FIELD resolving to a ui-namespace SDUI node renderer is a cross-namespace fallback no contract states; B ends it, A whitelists around it.
• Measured business pull — the leak is measured (field object + dead max_length in DOM attrs), but only on the built-in no-registerAllFields() path; no user report.
• AI-agent error-resistance — B is the strict shape (a field type either resolves a field widget or takes the declared default branch); A is consumer-side stripping, the tolerance pattern that hides authoring errors.
• Startup scope discipline — A is the smaller diff; B is the smaller surface (one fallback rule removed) but is a behaviour change and needs this ruling.

Recommendation: B — form-field resolution stops falling back to bare-name ui components; email/password then take the default input branch (the implementer must verify that branch renders a usable input; #5253's evidence suggests it does, and #5253 fixes that branch's ceiling defect independently). Adopt A's DOM-props whitelist only if some bare-name non-field component is meant to stay reachable from form fields — and then as its own ruled card, not silently.

---

Generated by Claude Code

[os-elon]

Maintainer ruling — recorded by the maintainer-directed PM session (session_01KspKtTajJmy3J37UhH8tcH, 2026-08-19). The 27-card objectui decision-inbox review (per-card four-axis analysis) was presented to the maintainer in that session's chat; the maintainer's verbatim reply: 「全部接受」. Adopted ruling, restated in full:

Ruling: Option B — stop the cross-namespace fallback

• Form-field type resolution stops falling back to ui-namespace SDUI node renderers; a FormSchema field type either resolves a field:-namespaced widget or takes the declared default input branch. email/password then land on the default branch.
• Implementer must verify the default branch renders a usable input for these types — 内建 form 的 default 回退分支有和 #5201 完全相同的 ceiling 缺陷:max_length 拿不到上限,只在 DOM 上留下失效属性 #5253's evidence suggests yes, and its ceiling defect on that branch is already fixed (merged PR fix(components): enforce the declared max_length ceiling on the form default fallback branch #5276), which is why B is now safe to execute.
• Option A (a toDomProps whitelist for the bare-name path) is rejected as the primary fix — consumer-side stripping that hides authoring errors while a form field still lands in a non-field component. If some bare-name non-field component turns out to need to stay reachable from form fields, that returns as its own ruled card, not as a silent widening here.

State: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 16

Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5254-form-field-crossnamespace-fallback
Worktree: objectui-issue-5254
Domain: repo:objectui
File surface: the form-field type-resolution path — locate it by reading and declare the real surface in the PR (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: yes — this removes a resolution fallback, so a spelling that resolves today stops resolving. The ruling's own words: it is "a behaviour change and needs this ruling" — and it has it. Declare it; do not soften it.
Serial constraints cleared: in-flight are #5269 (packages/plugin-view), #5299 (packages/plugin-dashboard), #5257 (packages/core) — all disjoint from the form-field resolution path. If your located surface overlaps any of them, stop and report before editing.

The ruling — maintainer, 2026-08-19, verbatim 「全部接受」

Recorded on this card by the maintainer-directed PM session session_01KspKtTajJmy3J37UhH8tcH. Option B:

Form-field type resolution stops falling back to ui-namespace SDUI node renderers. A FormSchema field type either resolves a field:-namespaced widget, or takes the declared default input branch. email / password then land on the default branch.

⛔ Option A is rejected as the primary fix — a toDomProps whitelist for the bare-name path is consumer-side stripping that hides authoring errors while a form field still lands in a non-field component. If some bare-name non-field component turns out to genuinely need to stay reachable from form fields, that returns as its own ruled card, not as a silent widening here.

⚠️ The one thing the ruling requires you to verify, not assume

"Implementer must verify the default branch renders a usable input for these types."

#5253's evidence suggests yes, and its ceiling defect on that branch is already fixed (merged PR #5276) — that is precisely why B became safe to execute. But the ruling puts the verification on you.

So: actually render email and password through the default branch and check the result is a usable input — not just that the DOM leak stopped. A fix that ends the leak by rendering something unusable is worse than the leak, and the leak is currently unreported by any user.

The defect being fixed

A form field with type: 'email' falls through bare-name resolution into a ui-namespace SDUI node renderer, leaking the field object and a dead max_length into DOM attributes. Measured, but only on the built-in no-registerAllFields() path.

Verification

• Re-derive on current origin/main first; confirm the fallback still exists and still has this shape.
• Pin both halves: the leak is gone and email/password render a usable input via the default branch.
• Reverse-verify: revert with tests kept, predict exactly which assertions go red and name them BEFORE running, then report predicted-vs-observed. Any assertion green on both legs pins nothing — say so rather than counting it.
• Counter-probe every zero with a known-present neighbouring term.
• ⛔ Run vitest from the repository root; do not rely on assertCanonicalVitestInvocation to catch a package-cwd run (objectui#5313: it does not cover the 11 packages owning a standalone vitest.config.ts).
• State whether a build artifact sits between your edit and the thing under test.

Changeset: judge it — a removed fallback is a behaviour change. If breaking, minor with the semantics spelled out in the body; if you judge the fallback was never a contract, patch with the reason stated. ⛔ NEVER major — objectui's major is pinned to @objectstack's major. Either answer is defensible; an unstated one is not.
⛔ Do not edit content/docs/releases/, docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md.

---

Generated by Claude Code