Files
MailUI4Agents/client/electron/test/manual
JianFeeeee ababe4ae56 fix(webui): 壁纸被不透明层盖住 —— 玻璃不再层层相乘 + 浅色表面类全部接管
用户报的:「webui 目前在壁纸底上叠了太多不透明层,导致壁纸效果很差,几乎看不出来」,
追问后补充:「不只是玻璃,而是很多界面是不透明的」。两句都成立,是两个叠加的原因。

## ① 玻璃层层相乘

每层面板都吃同一个不透明度 a,两层就是 1-(1-a)²。a=0.82 时两层 0.97、三层 0.995
—— 壁纸在数学上被吃掉,而且每层各做一次 16px 模糊,图案被糊成灰块。
改法:玻璃只出现一次(外层 0.62 + 18px 模糊;嵌套层只留 0.3 色调且不再模糊;
第三层透明)。同时把遮罩 24%→12%、照片自身模糊 8→4px(那张被洗白的锅之一)。

## ② 14 个浅色表面类根本没被接管("很多界面是不透明的"就是这条)

旧规则只接管 white / gray-50 / slate-100,而源码里在用的是
gray-100(24 处)、blue-50(17)、red-50(13)、blue-100(8)、gray-200(8)、green-50(8)…
—— 全是实心的,正好盖住壁纸。

清单改为**从源码用法生成**(`scripts/gen-background-takeover.mjs` → 生成的 CSS,
构建前自动跑),因为手写清单必然烂;判据保证"源码里出现的浅色表面类必须都被接管",
并明确排除页面底(gray-50/slate-100 必须保持**全透明**,不能被改成半透明)。
按钮/徽标(*-600/700、chrome-600/700)**故意保持不透明**:小控件可读性优先
(index.css 里原有注释记着实测 4.46:1 的教训)。

## 判据

- `test/background.test.mjs` 23 条(新增 8 条):玻璃算式(两层 ≤0.85)、外层 ≤0.70、
  嵌套规则存在、**判据自检**(旧值 0.82 必须算得出 >0.95)、表面类覆盖、页面底不得进清单、
  清单非空跑。犯过一次错:第一版把判据追加在 `process.exit()` **之后** ⇒ 根本没执行,
  从"测试数没变"才发现。
- `test/manual/wallpaper-layers-verify.mjs`(真实渲染,自带无头 Chromium):
  用**纯红壁纸读绿通道**测有效不透明度(纯色下 backdrop-filter 不影响读数)。
  面板 p95:**修复前 82% → 修复后 62%**;反向对照(改回旧值)能分辨 ≥10 个百分点;
  深色照片面上面板仍是浅底;关掉壁纸的同坐标对照更实。5/5。
  过程中作废了两个指标:只看绿通道会把深色元素误判成"盖死";"面积占比"类阈值
  (Δ≥8/≥40)在 0.97 时仍会蹭过门槛,饱和而无分辨力 —— 同坐标比值才可信。

## 交付

已部署(网关内嵌 WebUI 重建):线上 CSS 已含 `--bg-glass-inner`、嵌套规则与 14 个接管类。
2026-09-14 08:09:22 +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 规则存在。

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