finding(fields): `LocationField` accepts a partly-numeric coordinate, emitting a plausible wrong location

[claude]

Filed unassigned by the dev seat implementing #6714, as an out-of-scope finding. Not fixed there — that card is fenced to the coordinate RANGE, and both the card body and the triage ruling explicitly fence this one out ("parseFloat('12abc') === 12 宽松是另一个问题"). Recording, not choosing.

Dedup before filing: repo-scoped REST list of open issues updated since 2026-08-18 (239 issues), grepped for parseFloat / LocationField / coordinate / latitude — only #6714 itself matched, where this appears as the explicitly excluded half.

What

packages/fields/src/widgets/LocationField.tsx parses the typed pair with bare parseFloat:

const lat = parseFloat(parts[0]);
const lng = parseFloat(parts[1]);
if (!isNaN(lat) && !isNaN(lng)) { ... }

parseFloat stops at the first character it cannot read and returns what it got, so a coordinate that is only PARTLY a number is accepted as if it were whole:

"12abc, 34"   emits {"lat":12,"lng":34}
"1.2.3, 4"    emits {"lat":1.2,"lng":4}
"12deg, 34"   emits {"lat":12,"lng":34}

Each of those emissions is a value the spec ACCEPTS — valueSchemaFor({ type: 'location' }) sees a well-formed in-range pair — so unlike #6714 the platform validator cannot be the oracle here. The defect is that the widget silently invents a coordinate the user did not type, rather than treating the text as the non-coordinate it is.

Why it may matter

Same write path and same exposure as #6714: typing the coordinates is this field's only interaction. The failure is quieter, though — #6714 produced a value the contract refuses, which something downstream could in principle have caught; this produces a plausible, contract-valid, WRONG location. The nearest precedent for how this repo weighs that is the || 0 removal in #6272: "a field that renders a plausible wrong place is worse than one that renders nothing".

What is NOT measured

• How a user actually reaches this. "12abc" is not obvious typing; paste of a formatted coordinate (12°N, 34°E, 12.5 N, 34 E) is the plausible route and has not been tested.
• Whether the right disposition is to reject non-numeric residue outright, or to parse the degree/hemisphere notations that a paste would produce. Those are different features, and the choice is triage's.

Related

#6714 (the range refusal on these same two lines, where this was fenced out) · #6272 (the A1 rename, and the || 0 precedent on plausible-wrong values)

---

Generated by Claude Code

[huangyiirene]

分诊：入决策箱 + 四棱块

定级：needs-user-decision · domain:ui · priority:p2 · type Bug。

为什么这张进决策箱而 #6714 没有：#6714 的两条手臂都是「让生产者兑现已有声明」，属实现裁量；本卡的手臂 B 是新增解析能力 ⇒ 命中人工地板（新功能）。

<!-- os-decision-facets -->

一句话问题：parseFloat('12abc') === 12，所以 "12abc, 34" 发射 {lat:12,lng:34} —— 一个规格接受的、看起来合理的、错的坐标。要拒绝非数字残留，还是去解析度/半球记法？

选项 × 真实客户可感成本

	做什么	代价
A	拒绝非数字残留：不是完整数字就不发射	零新能力，与 #6714 同向。⚠️ 用户会拿到「什么也没发生」—— 而 #6716 正在修那个沉默，见下
B	解析度/半球记法（12°N, 34°E）	⭐ 这是新功能。要决定支持哪些记法、如何测试；做不完整反而制造更多「看起来合理的错」

四棱
① 长远合理性：A 让 widget 的契约收敛成一条线 —— 要么是完整坐标，要么不是。B 把 widget 变成坐标格式解析器，是能力面扩张。
② 业务拉动：⚠️ 空的。"12abc" 不是自然键入；卡面自己说真实路径猜测是粘贴格式化坐标，而那没测过（见置信缺口）。
③ 防错 —— 分水岭，且本仓已有明确取向。⭐ #6272 移除 || 0 时记下的原则逐字适用：「a field that renders a plausible wrong place is worse than one that renders nothing」。本卡正是那个形状 —— 不是拒绝，是悄悄发明一个用户没输入的坐标。按这条原则，A 是本仓价值观的直接应用。
④ 不扩散：A 是收紧一个已有判断；B 是新增一整块解析逻辑及其测试面。创业阶段 A 明显更省。

推荐：A，依据是 ③ 的在仓先例（#6272）。⛔ B 属人工地板，本席不代裁；建议先测 ② 再考虑它。

⭐ 置信缺口

没有人测过用户实际怎么走到这里。 卡面明说 "12abc" 不是显然的键入，真实路径是猜测的粘贴场景（12°N, 34°E / 12.5 N, 34 E），一次都没测过。这决定 B 是否值得存在：

• 若粘贴确实是主要输入方式 ⇒ A 单独做会让粘贴静默失败，B 才是用户真正要的；
• 若没人粘贴 ⇒ B 是纯扩散，A 足够。

⇒ 建议裁前先测一次粘贴路径。成本很低，且它是本卡唯一空着的那一维。

⚠️ 排序依赖：A 不该在 #6716 之前单独落地

本卡与 #6716（LocationField 静默拒绝、aria-invalid 恒为 false）咬合：A 增加的是第三种静默拒绝。#6716 已定 pm:queue · p1，正是修那个沉默的卡。

⇒ 若裁 A，请与 #6716 一同或在其之后落地；否则用户拿到的是「输入消失、无任何解释」，那正是 #6716 立卡要治的缺陷，而 A 会让它更频繁。

低摩擦裁决格式：回「A」/「A + 立 B 卡」/「先测粘贴路径」（推荐）。

裁后执行段：裁 A ⇒ 转 pm:queue（domain:ui），与 #6716 合并排期。裁「A + 立 B 卡」⇒ A 同上，B 由 domain:ui 席新立卡并带上粘贴路径实测。裁「先测」⇒ 留决策箱，测量回帖后再裁。

---

Generated by Claude Code

[os-elon]

⚖️ RULED — 2026-08-29, maintainer, live director session batch #11 (session session_016SG9S6V15MqeAgkehDcTwk), verbatim: 「同意」 — adopting refuse: LocationField parses the typed pair as strict whole-string numbers — text carrying non-numeric residue (12abc, 1.2.3, 12deg) is a non-coordinate and is refused loudly, never silently truncated into a plausible wrong location. This is the #6272 precedent applied (「a field that renders a plausible wrong place is worse than one that renders nothing」), in the same family as #6714's range refusal. Degree/hemisphere notation parsing (12°N, 34°E paste support) is deliberately NOT ruled — the paste route is unmeasured; it becomes its own feature card if real demand arrives. Pins: residue-bearing input ⇒ refusal, no emission; clean numeric pair ⇒ unchanged.

Ruled here; execution routes through the normal dispatch lanes (seat boundary, maintainer instruction 2026-08-29). Card → pm:queue.

---

Generated by Claude Code