Files
MailUI4Agents/client/electron/test/manual
JianFeeeee 0a4b98144c feat(webui): 通信二级页签与列表头一体 + 沉浸式(PWA 全屏)+ 日历滑动验收脚本
用户三条(同一线索):「通信页面的二级页面与其他位置极其割裂」、
「不支持沉浸式网页」、「日历页面还不支持左右滑动手势」。

## ① 二级页签不再割裂

页签原先是**带 shadow 的白色胶囊**浮在面板上,看起来像硬贴上去的另一套控件。
改成**下划线页签**:与列表头同一内边距、同一条下边框,选中态用蓝色下划线 +
`-mb-px` 压住分隔线(否则会出现"两条线"的接缝)。

## ② 沉浸式

根因不是 viewport(`viewport-fit=cover` 早就有了,安全区也接了
`env(safe-area-inset-*)`),而是**没有 Web App Manifest**:手机上"添加到主屏幕"后
打开仍然是带地址栏的网页。现在加了 `manifest.webmanifest`(`display: standalone`)
+ iOS 的 `apple-mobile-web-app-capable` / `black-translucent`(状态栏内容叠在页面上)。

manifest 放在**根路径**而不是 /assets/ 下:它里面的 `start_url`/`scope` 是相对
manifest 自己的 URL 解析的,挂在 /assets/ 下就得写 "../"。静态只挂了 `/` 与 `/assets/*`,
所以显式加了一条路由(并从 embed 读,而不是读磁盘 —— 前端产物必须与应用同源同版本)。
图标由项目唯一图标源生成 192/512(尺寸与声明一致,我用 struct 读文件头核对过)。

**实测**:`/manifest.webmanifest` → HTTP 200 `application/manifest+json`。

## ③ 日历滑动:补上真正的验收脚本

`test/manual/calendar-swipe-verify.mjs` 四条,含**反向对照**(纵向拖动不得翻页)
与前置断言。写它时又踩了一次自己的坑:标题真实格式是「2026 年 9 月」(数字与"年月"
之间有空格),我第一版正则按无空格写 ⇒ 匹配不到 ⇒ 三个值全是 null,
**看起来像"滑动没生效",其实是探针瞎了**。所以脚本里第一条就是"标题读得到"。

实测:9 月 →左滑→ 10 月 →右滑→ 9 月,纵向拖动不动。

## 顺带

把我为验收造的测试数据**归档**(不是删除):10 个 `/tmp/scrollprobe-*` 独立会话 +
12 封"滚动验收/窄屏验收样例"邮件。
2026-09-14 11:07:03 +08:00
..

手工浏览器实测脚本

不进 npm test —— 它们需要一个跑着的 Chromium 与一个活的 Gateway。 日常回归靠 ../narrow-layout.test.mjs(读源码验形态,无外部依赖)。

为什么两套都要

结构性断言守住「代码写成了什么形态」,量不出「按钮实际多大、点下去命中谁」。

窄屏那轮修复里最严重的一个 bug 是抽屉式侧栏(fixed ... z-50 铺满视口高度) 把底部导航最左那一项盖住 —— 按钮在那里、尺寸也够、md:hidden 之类的规则也 没写错,只有 elementFromPoint 才能发现它命中的是抽屉里的 SVG

用法

# 窄屏390pxiPhone 14 Pro+ 320pxiPhone SE
ADMIN_PW=<密码> npm run test:narrow

# 宽屏回归:窄屏修复不能把桌面改坏
ADMIN_PW=<密码> npm run test:wide

环境变量:

变量 默认 说明
ADMIN_PW 无(必填) 管理员密码
ADMIN_USER admin 登录用户名
AGENTMAIL_URL https://mail.jianfgit.xyz 目标地址
CDP_URL http://127.0.0.1:9222 浏览器 CDP 端点
PLAYWRIGHT /usr/lib/node_modules/playwright/index.mjs playwright 入口

浏览器用的是本机 systemd 托管的共享 Chromiumhomeagent-browser.service 通过 CDP 连上去开自己的标签页,用完关掉。没有它时先 systemctl start homeagent-browser

文件

文件 作用
narrow-probe-helper.mjs 连浏览器、登录、量盒子/溢出/命中区/命中测试
narrow-verify.mjs 窄屏 13 项验收
wide-regression.mjs 宽屏 5 项回归
inbox-group-verify.mjs 收件箱按会话分组
theme-verify.mjs 深浅两色的 WCAG 对比度
accent-verify.mjs 强调色(红/绿/橙/黄/蓝17 组配色,两模式各一遍
desktop-phase3-verify.mjs 桌面客户端:写信 + 附件 + 权限面板(见下)

narrow-probe-helper.mjs 里两个函数值得单独知道:

  • tapTargets(page, labels) —— 量 .tap 按钮的真实命中区(::after 伪元素的尺寸)。.tap 刻意不改变视觉尺寸,所以只看 boundingBox 会误判成偏小
  • hitTest(page, selector) —— 每个元素点下去是否命中自己。遮挡类 bug 只能这样查

accent-verify.mjs 存在的理由是一次真实事故:tailwind.config.jscolors 里同时写了固定 hex 与 accent() 两份 red/green/amber/orange/yellowJS 对象 字面量重复键后者胜出(不报错),而 index.css 当时没有对应的 --c-red-* 变量。rgb(var(--c-red-600) / 1) 里变量未定义 → 整条 background-color 声明 失效 → bg-red-600 退回透明、text-white 的白字落在白卡片上: 按钮看不见但点得动。所有静态检查都过,只有肉眼能发现。

因此这个脚本量的是实际计算值:它把类名注入真页面、读 getComputedStyle 把「背景透明」单独判为失败(那正是上述 bug 的指纹),再算 WCAG 对比度。

只以 hover: 变体出现的档(bg-red-700 / bg-blue-700不能放进探针: Tailwind 不生成未被使用的基础类,探它必然得到透明背景 —— 那是假阳性。 它们由 ../theme.test.mjs 的档位断言覆盖。

桌面客户端那一个(desktop-phase3-verify.mjs

它不连共享浏览器,而是自己起打包好的 Electron 应用xvfb + --remote-debugging-port 然后走一条贯穿全流程的链:

ADMIN_PW=<密码> DESKTOP_BIN=release/linux-unpacked/agentmail-web \
  node test/manual/desktop-phase3-verify.mjs
  1. 用桌面 UI 写一封信、带一个附件,发给 zcode
  2. 外部(直接打网关 API核验信真的在、附件真的挂着 —— 界面说「已发送」不算证据
  3. 这封信让 zcode 触发一次真实的授权请求(执行门禁)
  4. 在桌面的授权面板里点「同意」
  5. 外部核验:决策被记录 Agent 真把命令执行了(标记文件出现)

第 5 步是这条链的重点:它证明界面上的那一下点击真的走到了 Agent 那侧。 只验界面变成「已同意」的话,一个只在本地改状态、根本没提交给网关的实现也能全绿。

第一条判据是「应用渲染出内容了吗」(#root 有子节点)—— 白屏时后面每一条都会 以奇怪的方式失败,而真正的原因只以一条资源错误出现。这个脚本第一次跑就靠它抓到了 base 那个白屏缺陷(见 ../packaging.test.mjs)。

已知限制

headless Chromium 报告 hover: none,因此 .reveal(只在支持悬停的设备上隐藏) 在这里永远是可见的 —— 脚本只能验「触摸设备上可见」这一半, 「鼠标设备上隐藏」那一半靠 ../narrow-layout.test.mjs 检查 CSS 规则存在。

没有像素级视觉比对:字体差异下极脆,维护成本高于收益。