Found while implementing #5201 (the built-in case 'input' branch's ceiling dual-read), by sweeping the same file for the same defect class. Out of that card's scope — #5201's triage ruling scoped the work to the input branch, so this is recorded rather than fixed there.
观察到的现象(已实测,不是推断)
packages/components/src/renderers/form/form.tsx 的 default 回退分支 —— switch 里最后那个 default:,服务于既不是 BUILTIN_FIELD_TYPES 成员、又没有任何注册组件的 type —— 与 #5201 修复前的 input 分支逐字相同:它把 {...domFieldProps} 展开到元素上,从不读取声明的上限。
实测方式与 #5201 同法:在 worktree 里渲染内建分支(不调 registerAllFields()),字段 type: 'zzunknown',dump 元素的 getAttributeNames() 与 getAttribute('maxlength'):
max_length: 50 → attrs=["class","max_length","id","aria-describedby","aria-invalid","type","name"] maxlength=null
maxLength: 50 → attrs=["class","maxlength","id","aria-describedby","aria-invalid","type","name"] maxlength="50"
同一份声明按拼法分成两种结果:maxLength 有硬截断(巧合 —— 它恰好是合法 DOM 属性名),max_length完全没有上限,外加一个多余的、失效的 max_length="50" 属性(无效 HTML)。两个各自独立的缺陷。
对照:同一棵树上修复后的 input 分支给出 attrs=[...,"maxlength",...] maxlength="50",无游离属性。
为什么这是缺陷而不是风格问题
理由与 #5201 逐条相同,不重述:max_length 是本仓活着的编写拼法(注册路径的 widget 自 framework#1878 §3 起 dual-read;三个 form field 生产者都归一化它;packages/types 在多个 field 类型上声明它)。这条回退分支同样服务于手写 FormSchema 直接喂给渲染器的路径 —— 中间没有任何生产者做归一化。
为什么没有在 PR for #5201 里顺手一起修
#5201 的 triage ruling 明确把范围钉死在 input 分支,并要求实现者不要顺路加宽;dispatch 另行强调不要把一处修复扩成跨分支的行为改动。回退分支服务的是未知/未注册 type 的整个集合,不是一个点名的 widget,所以它值得单独判一次范围,而不是作为副作用落地。
起点
检索记录
search_issues 在 objectui 上跑过两轮关键词(default fallback branch / max_length / stray attribute / DOM),命中的 open 卡只有 #5201 本身与无关的 #5235,无重复单。
Found while implementing #5201 (the built-in
case 'input'branch's ceiling dual-read), by sweeping the same file for the same defect class. Out of that card's scope — #5201's triage ruling scoped the work to theinputbranch, so this is recorded rather than fixed there.观察到的现象(已实测,不是推断)
packages/components/src/renderers/form/form.tsx的default回退分支 —— switch 里最后那个default:,服务于既不是BUILTIN_FIELD_TYPES成员、又没有任何注册组件的type—— 与 #5201 修复前的input分支逐字相同:它把{...domFieldProps}展开到元素上,从不读取声明的上限。实测方式与 #5201 同法:在 worktree 里渲染内建分支(不调
registerAllFields()),字段type: 'zzunknown',dump 元素的getAttributeNames()与getAttribute('maxlength'):同一份声明按拼法分成两种结果:
maxLength有硬截断(巧合 —— 它恰好是合法 DOM 属性名),max_length完全没有上限,外加一个多余的、失效的max_length="50"属性(无效 HTML)。两个各自独立的缺陷。对照:同一棵树上修复后的
input分支给出attrs=[...,"maxlength",...] maxlength="50",无游离属性。为什么这是缺陷而不是风格问题
理由与 #5201 逐条相同,不重述:
max_length是本仓活着的编写拼法(注册路径的 widget 自 framework#1878 §3 起 dual-read;三个 form field 生产者都归一化它;packages/types在多个 field 类型上声明它)。这条回退分支同样服务于手写FormSchema直接喂给渲染器的路径 —— 中间没有任何生产者做归一化。为什么没有在 PR for #5201 里顺手一起修
#5201 的 triage ruling 明确把范围钉死在
input分支,并要求实现者不要顺路加宽;dispatch 另行强调不要把一处修复扩成跨分支的行为改动。回退分支服务的是未知/未注册 type 的整个集合,不是一个点名的 widget,所以它值得单独判一次范围,而不是作为副作用落地。起点
packages/components/src/renderers/form/form.tsx,switch 的default:分支case 'input'(内建 form 分支的 input 字段:legacymax_length拼法拿不到任何 maxlength 上限,只在 DOM 上留下一个失效属性 #5201 落地后)与case 'textarea'(内建 form 分支的长文本字段完全没有字数计数,同一个 maxLength 在两条渲染路径上给出两种体验 #3439/PR fix(components,fields): honour a declared character cap on the built-in textarea branch (#3439) #5200)—— 两者都用局部解构,而不是扩stripRendererOnlyProps共享剥离表(那张表喂checkbox/switch/select/default全部分支)max_length拼法拿不到任何 maxlength 上限,只在 DOM 上留下一个失效属性 #5201 的:getAttributeNames()+getAttribute('maxlength'),两半都断言检索记录
search_issues在 objectui 上跑过两轮关键词(default fallback branch / max_length / stray attribute / DOM),命中的 open 卡只有 #5201 本身与无关的 #5235,无重复单。