Files
Jyotisha/docs/testing/ios-keyboard-composer-20260915.md
T
Jesse_ChenandClaude Fable 5 899f955d4b docs(tasks): fold two mobile blockers into the reading-load round, brief touch targets and breakpoints
2026-09-15 的 UI 走查(web + 移动端)结果落盘。

并入 TASK-chat-reading-load:折叠层里的四列表在窄屏没有重排规则
(767 的卡片化只认三列,width:100% 又让 overflow-x 永不触发),它是
折叠能不能落地的前置;全局 input/select 是 14px,iOS 聚焦会把整页放大,
命中整条注册与资料录入漏斗。

新单 TASK-mobile-touch-and-breakpoints(BUG-695~697):消息操作按钮
命中区 27×34 且相邻只隔 1px;CSS 平板上限 900px 与 sidebar-state.ts 的
1024 不一致,901–1023 是混合态;报告域 720/760/860 三刀互不对齐,
761–860 目录已塌、正文还是桌面。含断点白名单契约测试作为防复发。

另加 docs/testing/ios-keyboard-composer-20260915.md:html/body overflow
hidden + 100dvh 外壳 + sticky 输入框 + interactiveWidget 只有 Android 认,
是键盘遮挡的风险形状,但代码断不了真假,交真机确认后再决定是否立单。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0155nFCgCHtoA7jhSDGmZmMu
2026-09-15 04:02:50 +00:00

56 lines
3.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 真机清单 · iOS 键盘是否遮挡输入框(2026-09-15)
**为什么需要人来测**:这一项无法从代码断定,也没有自动化替代。会话环境没有 iPhone、没有 Chrome、没有登录态。走查只能确认「风险形状成立」,不能确认「真的坏」。结论出来之前**不立修复单**。
## 代码侧已确认的事实
| 事实 | 位置 |
| --- | --- |
| 页面自身不可滚动 | `frontend/src/app/globals.css``html, body { width: 100%; height: 100%; overflow: hidden; }` |
| 应用外壳锁死视口高度 | `.group\/sidebar-provider[data-viewport] { height: 100dvh; overflow: hidden; }` |
| 输入框是滚动区外的粘性行 | `.composer-wrap { position: sticky; bottom: 0; }``.chat-panel``grid-template-rows` 把它排成独立一行 |
| 只声明了 Android 认的键盘策略 | `frontend/src/app/layout.tsx``viewport.interactiveWidget = "resizes-content"`。**iOS Safari 不支持这个属性,会忽略** |
| 没有任何 `visualViewport` 监听 | `grep -rn "visualViewport" frontend/src` = 0 命中 |
这是「app shell + 锁定高度 + 粘性输入框」的典型形状。iOS 在键盘弹出时不缩小布局视口,只缩小可视视口;系统自带的 scroll-into-view 兜底在 `overflow: hidden` 的外壳里没有可滚的东西。**但 iOS 也可能自行平移可视视口把输入框顶上来**,所以必须实测。
## 怎么测
设备:iPhone。两个浏览器各测一遍——**Safari** 和**微信内置浏览器**(后者用的是 WKWebView,行为可能不同,而且很可能是真实用户的主要入口)。
地址:`https://staging.jyotisha.chat`
### A. 聊天输入框
1. 登录,进入任意一个已有会话(不要用空首页,空首页的布局不同)。
2. 点一下底部输入框,等键盘完全弹出。
3. **看**:输入框整条是否还完整可见?发送按钮是否露在键盘上方?
4. 连打三行以上文字,让输入框自己长高(它 `max-height: 128px`)。**看**:长高之后是否被键盘吃掉?
5. 输入过程中,上方最后一条消息是否还看得见?还是被顶没了?
6. 收起键盘。**看**:页面有没有留下一块空白,或者整体位置偏了没还原。
### B. 长会话里的输入框
1. 找一个消息很多、需要滚动的会话,滚到中间位置(不在底部)。
2. 点输入框。**看**:弹键盘时页面有没有突然跳到别处。
### C. 登录页与资料录入
1. 退出登录,在 `/login` 点邮箱输入框。**看**:键盘弹出后输入框和「获取验证码」按钮是否都还可见。
2. 新账号走一遍姓名 → 出生日期 → 出生时间 → 出生地搜索。出生地搜索会弹下拉列表,**重点看**:下拉列表是否被键盘压住、能不能点到。
### D. 横屏
把手机横过来重复 A.2。横屏时键盘占比更大,最容易暴露。
## 怎么回报
每一条写「正常 / 有问题 + 一句现象 + 截图」。截图请**不要**带真实姓名、出生资料或会话内容——用一个测试账号,或者截图后把这些涂掉。
- 如果 A–D 全部正常:这一项关闭,记进本文件末尾,不开修复单。
- 如果任何一条有问题:把现象贴回来,我据此出修复单。预判的修法是引入 `visualViewport` 监听把键盘高度写进一个 CSS 变量,由 `.composer-wrap` 消费;但具体怎么改要看实际是哪一种坏法。
## 结论
> 待填。测完把结论写在这里(日期 + 设备 + 浏览器 + 逐条结果),不要另开文件。