Skip to content

🐛 批量更新页打开更新详情复用检查缓存并挡住重复点击 - #1719

Merged
CodFrm merged 2 commits into
mainfrom
fix/batchupdate-open-detail
Sep 7, 2026
Merged

🐛 批量更新页打开更新详情复用检查缓存并挡住重复点击#1719
CodFrm merged 2 commits into
mainfrom
fix/batchupdate-open-detail

Conversation

@CodFrm

@CodFrm CodFrm commented Sep 3, 2026

Copy link
Copy Markdown
Member

Checklist / 检查清单

  • Fixes mentioned issues / 修复已提及的问题
  • Code reviewed by human / 代码通过人工检查
  • Changes tested / 已完成测试

N/A — 无关联 issue，问题由维护者在批量更新页直接反馈；Code reviewed by human 待人工审阅。

背景

在 src/batchupdate.html 上点击脚本名查看更新详情时：

  1. 要等好一会儿才打开更新详情页；
  2. 等待期间没有任何反馈，可以重复点击。

读代码定位到根因：检查更新阶段已经把新版代码拉下来存进了 ScriptUpdateCheck 的记录缓存（cacheFull.list[].newCode，行内「更新」按钮装的就是这份），但 openUpdatePageByUUID → openUpdatePage → openUpdateOrInstallPage 第一句仍是 await fetchScriptBody(url)，为每次点击白跑一次网络往返。而 openInCurrentTab 实际是 chrome.tabs.create，所以点几次就开几个安装页。

改前构建上的复现（本地 mock server 记录真实请求，同一 tick 连点 3 次）：

hits pre-click: 3  →  hits post-click: 6        # 3 次点击 = 3 次重复下载
pages: install.html?uuid=37f9b7ee… ×3           # 开出 3 个安装页

本次改动

Service Worker（src/app/service/service_worker/script.ts）

  • 把 openUpdateOrInstallPage 拆成「拉代码」+「处理代码」两段，新增 prepareUpdateOrInstallPage；原方法退化为 fetchScriptBody 后交给它，静默更新判定、SkillScript 分支、临时代码写入逻辑原样保留。
  • openUpdatePage 增加可选 cachedNewCode：命中时直接进处理段，跳过网络拉取；并改为回报 boolean（打开安装页或完成静默更新为 true，拉取/解析失败为 false）。
  • openUpdatePageByUUID 从检查记录缓存取 newCode 传入，缓存缺失时按原路回退网络拉取；同时用 DAO 取到的完整 Script 直接传参，去掉原先拼半个对象所需的 @ts-ignore。

页面（src/pages/batchupdate/）

  • hooks.ts：新增 opening 状态与同步镜像 openingRef；onOpen 在请求进行中拒绝同一行的重复点击，失败（返回 false 或消息通道 reject）弹 notify.error；点击脚本名同样取消自动关闭倒计时。
  • components.tsx / mobile.tsx：ScriptName 增加 loading，打开期间 disabled + aria-busy + 转圈，桌面与移动两套视图一致。
  • 新增文案 key install:updatepage.open_failed，10 个语言包已补齐。

实现考虑

  • 为什么改 SW 而不是只加个 loading：加遮罩只能让「白等一次网络」变得好看一点；这次点击本来就不需要联网。复用缓存代码还有一个正确性上的好处 —— 打开的详情页与列表上展示的、以及「更新」按钮会装的是同一版代码。
  • 静默更新语义不变：缓存路径与网络路径都走同一个 prepareUpdateOrInstallPage，静默更新开关命中时仍然返回 2、不开安装页。
  • 防连点用 ref 而不是 state：setState 是异步的，挡不住同一 tick 内的连击；openingRef 同步落地，opening state 只负责驱动转圈。
  • 缓存陈旧：检查记录可能不是最新一次网络内容，但这正是列表当前展示的那一版；batchUpdateListAction 的更新路径本来也用这份缓存，两者保持一致。

已知限制

  • 缓存被 Service Worker 回收后的「回退网络拉取 → 失败 → 弹提示」分支，只有单元测试覆盖：真实会话里无法制造 SW 被回收的状态。
  • 打开完成后再次点击仍会开出第二个安装页 —— 这是完成态的正常行为，本次只挡进行中的重复点击。

建议审查重点

  • prepareUpdateOrInstallPage 拆分后，安装（update=false）与更新（update=true）两条既有路径行为是否完全不变。
  • openUpdatePage 由 void 改为 boolean 后，另一处调用方 requestCheckUpdate 不受影响。
  • 页面卸载（自动关闭 / 用户关页）时挂起的打开请求不会造成异常。

验证

npx vitest run src/pages/batchupdate src/app/service/service_worker/script.test.ts
# Test Files 4 passed | Tests 165 passed

pnpm run typecheck        # 通过
npx eslint <改动文件>       # 通过（pre-commit 钩子同样跑过 lint / prettier / i18n）
pnpm run check:i18n       # ✅ all locales match the en-US / en reference key sets

新增测试（均先写后红再实现）：

  • script.test.ts —— 命中缓存不再拉取 / 缓存失效回退拉取 / 拉取失败回报 false / 脚本不存在回报 false
  • hooks.test.ts —— 打开期间标记进行中且重复点击不重复发起 / 失败弹提示并解除转圈 / 消息 reject 同样反馈 / 点击取消自动关闭
  • components.test.tsx —— 桌面行打开期间 aria-busy + 转圈且拒绝点击 / 非打开态可点击 / 移动卡片一致

真实浏览器验证（node e2e/session.mjs + 本地 mock server，非提交进仓库的用例）：

改后 · 单击:      hits 2 → 2，新开 1 个 install.html，详情页显示 v1.0.0 → v2.0.0 与代码 diff
改后 · 连点 3 次: hits 2 → 2，只新开 1 个 install.html

已知的既有问题（与本 PR 无关，在干净树上同样失败）：src/pages/install/useInstallData.test.ts 有 1 条用例失败。

Screenshots / 截图

改动为行内转圈与失败 toast 的交互反馈，主路径修复后打开近乎瞬时，静态截图无法体现差异；上文以 mock server 请求数与标签页数量作为证据。

@CodFrm
🐛 批量更新页打开更新详情复用检查缓存并挡住重复点击
c73a876 
点击脚本名查看更新时，openUpdatePageByUUID 会重新 fetch 一次脚本代码，
而这份新版代码在检查更新阶段已经存进 scriptUpdateCheck 的记录缓存里
（行内「更新」按钮装的就是它）。用户因此要为每次点击白等一次网络往返，
期间页面又没有任何反馈，连点几下就会开出多个安装页。

- SW: 拆出 prepareUpdateOrInstallPage，openUpdatePage 命中缓存代码时
  跳过 fetchScriptBody；openUpdatePageByUUID 改为回报 boolean
- 页面: 打开期间行内转圈并同步挡住重复点击，失败弹 toast，
  点击脚本名同样取消自动关闭倒计时
@CodFrm CodFrm mentioned this pull request Sep 3, 2026
Merged
2 of 3 tasks
@cyfung1031

cyfung1031 commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator

#1721 (comment)

@CodFrm
🐛 更新页与安装页补齐骨架屏与异步中间态，失败不再被渲染成成功 (#1721)
fdb7648 
* 🐛 打开更新详情区分静默更新，忽略动作补齐逐条回执

页面此前无从判断服务端到底做了什么：openUpdatePageByUUID 在命中静默更新时
不开安装页却同样返回 true，用户点完脚本名只看到转一圈、什么都没发生；
IGNORE 分支根本没有返回值，页面只能 fire-and-forget。

- openUpdatePageByUUID / openUpdatePage 返回 "opened" | "silent" | "failed"
- IGNORE 逐条回报结果。忽略写的是脚本自身的 ignoreVersion，与检查缓存无关，
  因此缓存随 Service Worker 回收后忽略照样生效，这里如实回报而不是谎报失效
- checkScriptUpdate 的结果收敛成 TCheckScriptUpdateResult 并用 reason 区分
  「已有检查在跑」与真正的失败，页面才能分别提示

* 🐛 安装页补齐加载分档、代码骨架与提交忙态

从批量更新页点脚本名进来的必然是「更新」，加载屏却把上下文 chip 写死成
「脚本安装」，几百毫秒后再闪成「脚本更新」；描述写着「正在从来源下载」，
但这条入口的代码 Service Worker 早已备好，根本不下载。

- 状态屏按来路分档，未确知场景不渲染 chip（不猜），并补一条与就绪态操作栏
  等高的底部占位，避免就绪瞬间内容区高度再跳一次
- 暂存代码被定时清理回收时落到专属终态，出口换成「重新检查更新」——
  原来的「重试」在这个最常见的失败原因下重试多少次都是同一结果
- Monaco 实例就绪前渲染代码骨架，替代此前 340px 的纯空白
- toggleWatch / rejectExternalAccess 补忙态，install 加重入守卫：
  这两个动作全程不置忙态，连点会发出两次安装/两次决定

* 🐛 批量更新页补齐取数失败、检查空窗期与忽略/批量的中间态

取数失败时记录仍是空的，页面直接走到空态，把一次加载失败渲染成
「所有脚本均为最新（已检查 0 个脚本）」这条与事实相反的成功终态；
点「检查更新」到服务端广播回来之间页面完全静止，期间可以连点。

- 取数失败落错误终态：等宽 detail 框 + 重试 / 脚本列表出口
- 主动检查由本地 pending 立刻接管忙态，并把服务端的「正忙」「结果够新已跳过」
  「通道异常」三条回执分别说出来；跳过时就地清掉待反馈标记，
  否则会在下一次后台检查完成时冒出一条用户没点过的 toast
- 忽略复用与更新相同的行级阶段（working → success → 退场），不再 fire-and-forget
- 批量进行中互斥（行内勾选、两个批量按钮、全部恢复），避免两条进度互相覆盖；
  被「结果失效」中断时保留已完成条数，不把汇总抹掉
- 骨架补齐工具条（桌面）与顶部选择栏/底部操作栏（移动）占位，消除数据到达时的
  布局跳动，并加 role="status" / aria-busy；空态下重新检查不再整页闪回骨架
- 脚本名改用 aria-disabled + onClick 早退：disabled 会让浏览器不派发指针事件，
  正好在名字被截断、最需要看全名时把 tooltip 一起关掉，键盘触发后焦点还会掉到 body
@CodFrm

CodFrm commented Sep 7, 2026

Copy link
Copy Markdown
Member Author

#1721 (comment)

这里是优化体验，并没有修改任何的业务逻辑

@CodFrm
CodFrm merged commit 999d2cd into main Sep 7, 2026
6 of 9 checks passed
@CodFrm
CodFrm deleted the fix/batchupdate-open-detail branch September 7, 2026 06:17
CodFrm added a commit that referenced this pull request Sep 7, 2026
@CodFrm
🔀 Merge branch 'main' into fix/batchupdate-remove-autoclose
2e47120 
冲突全部落在 #1719 同样重写过的批量更新页上，按「保留 main 的新能力 + 删掉自动关闭」解：

- hooks.ts `runUpdates`：main 的批量互斥（batchRunningRef + try/finally）与中断汇总
  （interrupted）保留，循环换成本分支的可变队列 + 下标，失效时先自动重查续做；
  重查后仍失效才落到 recordExpired，并按 main 的口径留下 interrupted 汇总而不是抹掉进度。
- runIgnores / runCheckNow / onOpen / onRetryLoad 取 main，仅摘掉其中的 cancelAutoClose。
- components.tsx、mobile.tsx、components.test.tsx：保留 onRetryLoad，去掉 onCancelAutoClose
  与 AutoCloseChip。
- hooks.test.ts：删掉随功能一并移除的「点开更新详情停掉倒计时」用例；recheckYields 改回
  main 收敛后的 TCheckScriptUpdateResult；「中断保留已完成条数」补上第二次 record_expired，
  因为第一次现在会触发自动重查。
CodFrm added a commit that referenced this pull request Sep 7, 2026
@CodFrm
🎨 补跑 prettier，修掉 #1719 遗留的 5 个文件格式偏差
2d05287 
main HEAD(999d2cd) 的 Lint 就因这 5 个文件 fail，与本 PR 的改动无关，
纯机械 prettier --write，无语义变化。
CodFrm added a commit that referenced this pull request Sep 7, 2026
@mikemikimike @CodFrm
@cyfung1031 @claude
🐛 修复 Edge Dev 下脚本注入静默失效 (#1725)
b75124c 
* 🐛 restore ScriptCat registration health checks (#1724)

* 🐛 修复 @run-at context-menu：设置覆写不生效、菜单注册不上、脚本体自己的菜单被屏蔽 (#1718)

* 🐛 修复设置面板覆写运行时机在重新注册后失效

restoreJSCodeFromCompiledResource 用脚本自带 metadata 选择编译分支，
而设置面板改运行时机/early-start 只写 selfMetadata，导致全量重新注册
（扩展更新、切换启用脚本、改黑名单等）后覆写被丢弃：context-menu 脚本
恢复自动执行且不注册菜单项，early-start 退化为普通注入。

pushValueUpdate 判断 early-start 时同样只看自带 metadata，覆写而来的
early-start 脚本在 GM 值变更后不会重新编译，预注入代码里的值会过期。

close #1649

* 🐛 修复 GM API 权限校验忽略用户覆写的运行时机

GMApi.parseRequest 直接把 scriptDAO 里的原始 Script 放进 GMApiRequest，
metadata 没有合并 selfMetadata。PermissionVerify 对 context-menu 脚本的
GM_registerMenuCommand 免 @grant 豁免因此判不出来，浏览器里表现为
verify error {"api":"GM_registerMenuCommand","error":"permission not requested"}，
菜单项注册不上 —— 即 #1649 里「上下文菜单中没有出现执行选项」。

真实浏览器验证记录见 e2e/scratch/run-at-override/report.md（未入库）。

* 🐛 context-menu 包装不再屏蔽脚本体自己的 GM_registerMenuCommand

@run-at context-menu 的包装把脚本体塞进菜单回调时，回调开头把
GM_registerMenuCommand 连同 window./GM. 上的引用一起置为 undefined。
于是任何在脚本体里注册菜单的脚本，点菜单执行就会
TypeError: GM_registerMenuCommand is not a function 当场中断，
它自己的菜单项也永远注册不上——用户看到的是「GM_registerMenu 的菜单显示不出来」。
该置空还会污染页面 window 与该脚本的 GM 物件，且是持久的。

去掉这行，脚本体里的菜单注册照常工作。代价是脚本体每次被点执行都会重新注册
一次，内部条目累积（显示层按 groupKey 去重，不会出现重复菜单项，但同名项的
回调会被触发多次）。

真实浏览器验证记录见 e2e/scratch/ctx-menu-{display,fix}/（未入库）。

* ✨ 统一 example/tests 测试结果与人工验证反馈 (#1717)

* ✨ 统一 example/tests 测试结果与人工验证反馈

* 🔒 固定 sctest CDN 引用到框架提交

* 🎨 统一 userscript 诊断面板与测试描述

* 🔒 固定 sctest CDN 引用到最新框架提交

* Update sctest.js

* 🔒 固定 sctest CDN 引用到最新框架提交

* ✨ 增强统一测试诊断与面板反馈

* 🔒 固定 sctest CDN 引用到最终框架提交

* ✨ 优化 sctest 诊断面板与 frame 反馈

* 🔒 固定 sctest CDN 依赖版本

* ♿ 优化 sctest 面板可访问性反馈

* 🔒 重新固定 sctest CDN 引用

* 🎨 优化 sctest 面板指标与布局

* 🔒 固定指标优化后的 sctest CDN 引用

* 🐛 固定 sctest 耗时显示宽度

* ✅ 加固 UI 异步断言与 E2E 保存结果观察 (#1727)

* test: stabilize heavy network rules UI cases

* test: isolate UI files and await observable state

* ✅ 保留 UI 测试原有隔离配置

* ✅ harden async test observations

* 🐛 align E2E save expectations with failure cases

* 🔍 tighten test guard binding and toast observation

* 📄 补充 Agent 自主操作边界、指令冲突裁决与人类可读写作规范 (#1728)

现有 agent 文档规定了改动的质量门槛，但缺三层：agent 在两次人工决策之间可以自行做什么、
指令冲突如何裁决、以及写给人看的东西该怎么写。静态审查的依据：
整套文档没有一处把 agent 写成决策者（`decide` 的主语全是分类表或原则），因而产出「建议生成器」；
`material` 作为门槛术语被引用九次却从未定义，且在 pull-request.md 内有两种含义；
测试失败例外在 AGENTS.md 概括成两条而 owner 定义了六种；路由表是一次性分类；
人工指令能覆盖什么没有成文；以及全套文档没有任何一条关于行文的规范，
而 pull-request.md 提供的九级标题骨架会被当成表格来填。

本次补齐：范围内自行决策、交还决定须指名归属与阻塞点、不写可查证却不查的保留意见、
指令冲突裁决与人工指令覆盖边界、连续路由、`material` 定义、测试失败例外改交 owner 裁决、
自主操作边界、不稳定结果报告口径、面向人类读者的写作原则、文档集自身的指令预算。
PR 模板补一条不渲染注释；pull-request.md 明确其结构是待考虑项而非待填表格。

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

* 🐛 批量更新页打开更新详情复用检查缓存并挡住重复点击 (#1719)

* 🐛 批量更新页打开更新详情复用检查缓存并挡住重复点击

点击脚本名查看更新时，openUpdatePageByUUID 会重新 fetch 一次脚本代码，
而这份新版代码在检查更新阶段已经存进 scriptUpdateCheck 的记录缓存里
（行内「更新」按钮装的就是它）。用户因此要为每次点击白等一次网络往返，
期间页面又没有任何反馈，连点几下就会开出多个安装页。

- SW: 拆出 prepareUpdateOrInstallPage，openUpdatePage 命中缓存代码时
  跳过 fetchScriptBody；openUpdatePageByUUID 改为回报 boolean
- 页面: 打开期间行内转圈并同步挡住重复点击，失败弹 toast，
  点击脚本名同样取消自动关闭倒计时

* 🐛 更新页与安装页补齐骨架屏与异步中间态，失败不再被渲染成成功 (#1721)

* 🐛 打开更新详情区分静默更新，忽略动作补齐逐条回执

页面此前无从判断服务端到底做了什么：openUpdatePageByUUID 在命中静默更新时
不开安装页却同样返回 true，用户点完脚本名只看到转一圈、什么都没发生；
IGNORE 分支根本没有返回值，页面只能 fire-and-forget。

- openUpdatePageByUUID / openUpdatePage 返回 "opened" | "silent" | "failed"
- IGNORE 逐条回报结果。忽略写的是脚本自身的 ignoreVersion，与检查缓存无关，
  因此缓存随 Service Worker 回收后忽略照样生效，这里如实回报而不是谎报失效
- checkScriptUpdate 的结果收敛成 TCheckScriptUpdateResult 并用 reason 区分
  「已有检查在跑」与真正的失败，页面才能分别提示

* 🐛 安装页补齐加载分档、代码骨架与提交忙态

从批量更新页点脚本名进来的必然是「更新」，加载屏却把上下文 chip 写死成
「脚本安装」，几百毫秒后再闪成「脚本更新」；描述写着「正在从来源下载」，
但这条入口的代码 Service Worker 早已备好，根本不下载。

- 状态屏按来路分档，未确知场景不渲染 chip（不猜），并补一条与就绪态操作栏
  等高的底部占位，避免就绪瞬间内容区高度再跳一次
- 暂存代码被定时清理回收时落到专属终态，出口换成「重新检查更新」——
  原来的「重试」在这个最常见的失败原因下重试多少次都是同一结果
- Monaco 实例就绪前渲染代码骨架，替代此前 340px 的纯空白
- toggleWatch / rejectExternalAccess 补忙态，install 加重入守卫：
  这两个动作全程不置忙态，连点会发出两次安装/两次决定

* 🐛 批量更新页补齐取数失败、检查空窗期与忽略/批量的中间态

取数失败时记录仍是空的，页面直接走到空态，把一次加载失败渲染成
「所有脚本均为最新（已检查 0 个脚本）」这条与事实相反的成功终态；
点「检查更新」到服务端广播回来之间页面完全静止，期间可以连点。

- 取数失败落错误终态：等宽 detail 框 + 重试 / 脚本列表出口
- 主动检查由本地 pending 立刻接管忙态，并把服务端的「正忙」「结果够新已跳过」
  「通道异常」三条回执分别说出来；跳过时就地清掉待反馈标记，
  否则会在下一次后台检查完成时冒出一条用户没点过的 toast
- 忽略复用与更新相同的行级阶段（working → success → 退场），不再 fire-and-forget
- 批量进行中互斥（行内勾选、两个批量按钮、全部恢复），避免两条进度互相覆盖；
  被「结果失效」中断时保留已完成条数，不把汇总抹掉
- 骨架补齐工具条（桌面）与顶部选择栏/底部操作栏（移动）占位，消除数据到达时的
  布局跳动，并加 role="status" / aria-busy；空态下重新检查不再整页闪回骨架
- 脚本名改用 aria-disabled + onClick 早退：disabled 会让浏览器不派发指针事件，
  正好在名字被截断、最需要看全名时把 tooltip 一起关掉，键盘触发后焦点还会掉到 body

---------

Co-authored-by: wangyizhi <yz@ggnb.top>
Co-authored-by: cyfung1031 <44498510+cyfung1031@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
CodFrm added a commit that referenced this pull request Sep 8, 2026
@CodFrm
🐛 更新页不再倒计时自动关闭，记录失效改为自动重查续做 (#1720)
0f70a99 
* 🐛 更新页不再倒计时自动关闭，记录失效改为自动重查续做

自动弹出的批量更新页带 autoclose=30，30 秒后 window.close()，用户还没读完
更新说明页面就自己没了(#1715)。倒计时是在补偿「抢焦点弹出一个没人要求的标签
页」，方向反了：整套机制连同 URL 参数、药丸组件与三个 i18n key 一并移除。

页面因此会长时间开着，这暴露了原本被 30 秒关窗掩盖的问题：批量更新记录只存在
Service Worker 内存里，SW 被回收后点更新只会拿到 record_expired。现在首次失效
自动重新检查一次并接着做完剩余条目，重查后已是最新的条目静默出队、不计为失败，
二次失效才提示用户重新检查。

close #1715

* 🎨 补跑 prettier，修掉 #1719 遗留的 5 个文件格式偏差

main HEAD(999d2cd) 的 Lint 就因这 5 个文件 fail，与本 PR 的改动无关，
纯机械 prettier --write，无语义变化。

* 🐛 批量更新页全局复用唯一窗口
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@CodFrm @cyfung1031