jianf/MailUI4Agents
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
678 Commits 1 Branch 0 Tags
0c6c506d7af3f4c98887f0e0a2002b631f4d10e2
Commit Graph

3 Commits

Author SHA1 Message Date
JianFeeeee
e29f38b151 跨端: 页面转场 + 主题切换交叉淡出（用户：「加页面转场，因为是桌面应用了」+「深浅色切换也加动画」） 
## ① 页面间转场（`pageTransition`）

用户要的是"因为它是桌面应用了"—— 桌面端的页面切换有转场是基本预期。

官方文档（`ts-page-transition-animation`）给了两条关键信息：
· 「当路由（**router**）进行切换时，可以通过在 `pageTransition` 函数中自定义
  页面入场和页面退场的转场动效」；
· 「为了实现更好的转场效果，**推荐使用 Navigation 组件和模态转场**」。

⇒ 所以**两套机制各归各位**，不混用：
  · 走 `router` 的独立页（管理页 / 邮件详情独立页 / 写信独立页）→ `pageTransition`；
  · 应用内 `Navigation` 跳转（邮件详情 / 写信，都走 `pushPath`）→ 已有
    `geometryTransition`（上一轮加的共享元素转场）。

数值照 WebUI `rise-in` 的关键帧（`index.css:1298-1307`）逐字对齐：
    from { opacity: 0; transform: translateY(4px) }
    to   { opacity: 1; transform: none }
⇒ 淡入 + 上浮 `Theme.riseInOffset`(4vp)，时长 `Theme.durRise`(200)。

★ 退场**只淡出、不做位移**：两端都位移会看起来互相推挤。

## ② 主题切换的交叉淡出

这是**平台机制差异**，不是"懒得做"：

· WebUI 切主题是**免费**的 —— CSS transition 挂在 `background-color` 上，
  主题换的是 CSS **变量**，于是每个元素各自补间（`index.css:1169` 给
  button/a/input/textarea/select 都挂了）；
· ArkUI 的主题走 `app.setColorMode()`，而界面颜色是**系统资源**
  （`$r('sys.color.*')`）。`animateTo` 只能补间**数值属性** ——
  "把一个资源换成另一个资源"没有中间值 ⇒ 实测整屏同时跳变（闪一下）。

⇒ 自己造一个"旧屏淡出"：
  ① 切主题**之前**用 `getComponentSnapshot().get(id)` 抓当前界面；
  ② 立刻切主题（底层已是新主题）；
  ③ 把位图盖在最上层、`opacity` 1 → 0 补间 ⇒ "旧界面淡出、新界面透出"。

新增：
· `Motion.captureForThemeFade(ui, rootId)` —— 抓图，失败返回 `undefined`；
· `Theme.durThemeFade = 260`（整屏变化比单组件入场慢一点才不刺眼）；
· `MainPage` 根 Stack 加 `.id(THEME_FADE_ROOT_ID)`（**常量**，两处拼错不报错、
  只表现为"动画静默不发生"）+ `themeFadeImage`/`themeFadeOpacity` 两个状态
  + 最上层那层 `Image`；
· `toggleTheme` 拆成"带动画"与 `applyThemeNow`（**不含动画**）两条路，
  共用同一份状态变更 —— 抓图失败 / 系统关掉动画时直接切主题
  （**功能优先于观感**：不能因为动画失败而切不了主题）。

★ 两个必须做的收尾（都不是可选）：
  · 动画结束后**清空 `themeFadeImage`** —— 留着是一张**整屏大小**的 PixelMap
    常驻内存，而且它盖在最上层会**吃掉所有触摸事件**（界面看着正常但点不动）；
  · 那层加 `hitTestBehavior(HitTestMode.None)` —— 动画期间用户可能正好在点按钮。

★ 默认跟随系统：**本来就已经是**（`Appearance.theme` 初值 `'system'`，
  `AppearanceStore` 与 `Models` 两处都是），本轮未改，只是确认了。

## 验证状态（如实）

✓ 编译通过；设备上装包后进程存活、无新 jscrash
✗ **动画本体没有在设备上看到**：
  · 页面转场与主题淡出都是 200-260ms，而 `snapshot_display` 往返 1.5-3s
    ⇒ 探针比被测对象慢一个数量级（同 `harmony-morph-unverified-middleframes`）；
  · 主题淡出还额外需要"已登录 + 找到主题开关"，而我在清 preferences 之后
    登录流程没能用 `uitest uiInput` 走通（`inputText` 追加而非替换，
    把地址栏填成了 `https://exm/api/v1https://mail.jianfgit.`）。

⇒ 这两条的**结构与接线**有判据/编译保障，但"动起来好不好看"只能由真机确认。
   我不声称已验 —— 与既有的 morph 那条同一个诚实口径。
 2026-09-21 17:36:40 +08:00
JianFeeeee
b6b50cbb88 修复: 套件因"清单自检"停了整整一天（一条判据都没跑）—— 补接线 3 个从未进 SUITE 的文件 + 修 2 处裸 readFileSync + 守卫补报"因此没有跑任何判据" 
pi 报的 `ran`/`checks` 双计**早已修掉**（`d23ef69`，他读的是它的祖先 `2774b00`）。
但顺着那条线实测，发现了一个**更严重的现况**：**套件一条判据都没在跑。**

## 一、★ 现况：`run-all.mjs` 输出只有一行，0 条判据

```
$ node test/run-all.mjs
这些判据文件没接进套件（写了却不会跑）：test/harmony-push-optin.test.mjs、…
退出码=1        stdout 0 行、stderr 1 行（build 与 install **两个相位都死**）
```

自检 2（"test/ 下每个 *.test.mjs 都要在清单里"）在**跑任何判据之前** `process.exit(1)`。

**逐提交对照（worktree 隔离）**：

| 提交 | 套件 |
|---|---|
| `cfe7808^` | `RESULT files=26 ran=23 checks=332 …`（正常）|
| `cfe7808`（09-16 07:46，加了 2 个文件）| **一行"没接进套件"，0 条** |
| `c523c21`（09-17 17:43，又加 1 个）| 同上 |

⇒ 整仓**超过一天没有任何判据读数**，而失败信号只有那一行 ——
**看起来像环境问题**，不像"套件坏了"。三个文件**从未**进过 SUITE（`git log -S` 查证：0 次提及）。

## 二、修

1. **接线 3 个文件**（`harmony-push-optin` 4 / `harmony-reply-target` 7 / `harmony-widescreen` 6 条）。
2. **接线后立刻暴出 2 处违规** —— 这是"漏接线"的**第二层后果**：不只它自己不跑，
   **连它自身的违规也没有任何东西会看见**：
   - `harmony-reply-target.test.mjs:189` 裸 `readFileSync` 读 `.go` ⇒ 改走 `code()`
   - `harmony-apibase.test.mjs:266` 裸 `readFileSync` 读 JSON ⇒ 改走 `prose()`
   （两条在纯净 HEAD 上**都已存在**，`criteria-hygiene` 第 2 条现在 6/6 绿。）
3. **守卫补报后果**：原来只说"这些文件没接进套件"，**没说"因此本次一条判据都没跑"**。
   ⇒ 补上那句 + 说明"修法是把文件接进 SUITE（不是改这里）"。
   **守卫本身保留**（漏接线不该静默），但**它要为自己造成的后果作证**。
   变异验证：临时摘掉一条 ⇒ 新报文出现；还原逐字节一致。

## 三、★ 我接线时被自己写的注释绊了一次（值得记）

`criteria-hygiene` 第 3 条扫"用了 `code`/原文读取/`bytes` 却没 import"，而它**不剥注释**：
我在注释里写了"那个入口保留注释"**并带上括号**，它报「用了 … 但没 import」。
⇒ **"注释里说明禁令"不等于"违反禁令"**（我们早立的规则），
而其镜像也成立：**注释里提到函数名会被判据当成使用**。两个方向都得当心。

## 四、测量（29 个文件，两个相位都活了）

| 相位 | RESULT |
|---|---|
| build | `files=29 ran=29 checks=440 pass=438 fail=2 red=8 broken=0 unreported=0` |
| install | `files=29 ran=27 checks=428 pass=427 fail=1 red=7 broken=0 unreported=0` |

`broken=0 unreported=0`（接线前那三个文件是 3/3 —— 它们自报不了条数）。
剩下 8 条红**都不是本次改动**：`narrow-layout`/`nav-merge`/`harmony-presets`/`build-stamp`/
`commit-hygiene` 等是**并发会话未提交的工作**（`harmony-nav` 正被改），
在纯净 HEAD 上它们**看不到**（因为 HEAD 上套件根本没跑）。
 2026-09-17 18:43:00 +08:00
JianFeeeee
9c6e9c66ad 跨端: 修复: 鸿蒙客户端"连不上服务器"—— 地址补 /api/v1 + 失败分类成人话（含网络白名单固化） 
症状
  鸿蒙客户端（client/harmony）连不上服务端，界面只显示"无法连接"，用户无法自助；
  而服务端 HTTPS 完全正常：https://mail.jianfgit.xyz/health → 200、
  /api/v1/auth/me → 401、/api/v1/events/stream → 401（Let's Encrypt *.jianfgit.xyz，
  TLS 校验通过；代理与直连 http://127.0.0.1:8180 行为一致）。

根因（两条，逐条核实过，其中一条**推翻了原判断**）
  ① apiBase 是"API 前缀本身"（ApiClient 里拼的是 '/auth/login' 这类相对路径），
     而 Ui 只做 trim+去尾斜杠：用户若只填 `https://mail.jianfgit.xyz/`，请求就打到
     `https://mail.jianfgit.xyz/auth/login` ⇒ 404，客户端再把它压成"无法连接"。
     **这是本次故障最可能的直接原因。**
  ② 默认值 `http://192.168.2.60:8180/api/v1` 是明文 + 写死内网 IP：手机不在同网段
     就永远不通（mail.jianfgit.xyz 解析到的就是这台内网机）。
     ★ 但"鸿蒙默认禁止明文 HTTP"这条**不成立**，已按本机离线官方文档核实：
     `devecocli docs read .../使用HTTP访问网络/http-request` 的《明文HTTP访问权限配置说明》
     写明 cleartextTrafficPermitted "默认为 true"，Network Kit 默认允许明文；
     另有 FAQ《Stage模型如何配置支持http明文传输》："无需配置，支持HTTP明文传输数据"。
     ⇒ network_config.json 按"显式固化意图"处理（照文档形状写对，但**不冒充**它是修复）。
     本机 SDK @ohos.net.http.d.ts 里确实有 2300997 Cleartext traffic not permitted（since 18），
     所以那条错误码在客户端被建成一条可读提示，而不是被忽略。

改法
  · 新增 model/ApiBase.ts（纯逻辑，无 @ohos，判据能用 node 直接跑）：
    normalizeApiBase（去尾斜杠**但不咬协议 //**、末尾没有 /api/v1 就补、已有的一字不动）、
    validateApiBase（自带修法的中文提示 + "公网明文才告警、内网明文不误报"）、
    describeFailure（404 自己写文案并点名 /api/v1；其它状态码让服务端文案说话；
    网络层按 2300006/2300007/2300028/2300997/2300998/2300058-60-77 分类成人话）。
  · Config.ets：DEFAULT_API_BASE → https://mail.jianfgit.xyz/api/v1。
  · ApiClient.ets：setBase/init **都**过 normalizeApiBase（唯一闸口 ⇒ 老装机里已经存下的
    坏地址在读回时就治好，光改默认值救不了它）；ApiError 带 nativeCode；错误路径改走
    describeFailure；404 的提示指向"地址少了 /api/v1"。
  · LoginPage.ets：地址先校验后持久化（不合法**不落库**、给可执行提示），明文警告常驻渲染；
    SettingsPage.ets：添加账号同样校验（多账号库直接喂 SseService，坏地址会让该账号的实时
    通道永久连不上）；AccountManager/SseService 落库与建连时各自再归一化一次。
  · 新增 resources/base/profile/network_config.json：按官方文档形状把内网明文
    （192.168.2.60 / 10.0.2.2 / localhost）显式列进 domain-config 白名单。
    文档给的就是这个**固定路径与文件名**，不需要在 module.json5 里写引用
    （仓库里既有的 HomeAgent 工程同样是这么放的）。
  · 新增判据 test/harmony-apibase.test.mjs（13 条）并接进 run-all.mjs 的 SUITE：
    值判据**直接跑** model/ApiBase.ts；.ets 那几条是**静态**接线判据（本机无设备）。

验证（都真跑过）
  · cd client/harmony && devecocli build clean && devecocli build
    → BUILD SUCCESSFUL in 7 s 186 ms；entry/build/default/outputs/default/entry-default-signed.hap
    存在（1214592 B，15:14）。
  · 解包 HAP：resources/base/profile/network_config.json 在包里、JSON 可解析、
    cleartextTrafficPermitted=true 且白名单含 192.168.2.60/10.0.2.2/localhost；
    bundleName 仍是 com.jianf.agentmail，module.json 没有多余的 metadata/securityConfiguration。
  · devecocli check lint → 0 error；我改过的文件**零发现**（总工性从 8 降到 7，
    顺带修掉 LoginPage 一条既有的 await-thenable）。
  · node --experimental-strip-types --no-warnings --test test/harmony-apibase.test.mjs
    → ℹ tests 13 / pass 13 / fail 0。
  · 变异验证 11/11 全红且**红在对应那条**（在 /tmp 的独立 worktree 里做的，不碰共享树）：
    归一化不补后缀、去斜杠咬掉协议、404 用通用文案、401 拿通用文案顶掉服务端原因、
    网络码不再分类、默认地址退回明文内网、setBase 直接赋值、登录页去掉守卫、
    内网白名单关掉明文、出现第二处自己拼 /api/v1、守卫变成空壳。
    （M8 第一次是**假绿**——只判了方法声明、没判调用点；改成切出 doLogin 方法体后再判才红。）

未验到（别把"编译过了"读成"连通了"）
  · **没有**在真机/模拟器上点过一次登录：本机当前无设备在线，所以"真的连上了服务端"
    这件事本轮**未被验证**；已验证的只是"地址会被补成带 /api/v1 的形态""构建产物正确"。
  · network_config.json 的**实际效果**未验：按官方文档明文默认就允许，这份文件是显式固化，
    没有做"关掉它再对比"的实验（也无法在无设备时做）。
  · DNS/超时/证书这几条分类的文案是按 SDK 错误码写的，**没有构造真人故障去实测**
    （即没有真的把 DNS 打坏、把证书换成自签来看提示）。
  · 登录页那条"未 /api/v1 会 404"的因果链是从服务端路由 + 客户端拼接方式推出的，
    没有用 curl 对 `https://mail.jianfgit.xyz/auth/login` 实打一次取证。
  · test/run-all.mjs 在本机（node v24.14.1）**本来就是红的**：它只认 `# pass N`，
    而 node 24 打的是 `ℹ pass N` ⇒ 25 个文件里 21 个被记成"没自报条数"。
    这是既有环境漂移（已在 HEAD 的 worktree 里复现同样的红），**本次没有动它**，
    所以新判据虽然已登记进 SUITE，要等 runner 的 marker 解析修好才会被套件真正计数。
 2026-09-15 15:15:17 +08:00