Commit 0f147b5
committed
fix: 修响应头总数永远为 0 的根因 —— onUpdated(loading) 与 webRequest 的写入竞态
排查链路:先用 curl 拉真实 GitHub 主页响应头跑了一遍 normalizeHeaders + pickHeaders,确认逻辑产出 4 个 picked header(server / vary / set-cookie / content-type)—— 不是 0。模拟脚本验证响应头链路本身没问题,那 0 只能是 data.main 整体没被写进 storage。
看 background/index.ts 找到嫌疑:
chrome.tabs.onUpdated.addListener((tabId, changeInfo) => {
if (changeInfo.status === 'loading') {
...
clearTabSession(tabId) // 把整个 tab storage 删了
...
}
})
而 chrome 不保证 tabs.onUpdated 的 'loading' 事件与 webRequest.onHeadersReceived 的 main_frame 触发先后顺序。常见 navigation 链上 'loading' 反而在 headersReceived 之后触发——导致刚被 webRequest 写入的 data.main 立刻被 clearTabSession 清掉,主文档响应头永远丢失。这能完美解释「响应头一直是 0」:写一次清一次。
修法两步:
1. onUpdated(loading) 不再 clearTabSession,只清 timer 和 badge。storage 留给 webRequest 自己管理写入语义。原本 clearTabSession 是想"新页面开始加载就清旧数据",但这个清除的副作用比预期大——把 webRequest 即将写入的 main 也清了。
2. webRequest.onHeadersReceived 处理 main_frame 时,显式做"开始新页面"的清理:data.apis = [] / data.frames = [](已有)+ delete data.page + delete data.dynamic(新增)。这样新页面的旧 page 检测和动态采集结果不会残留,main 是新写入的不会被清。
clearTabSession 的导入和函数本身保留——onRemoved(tab 关闭)时仍然调用它,这才是 storage 真正应该被清的时机。
修完后 GitHub / B 站 / 任何主文档响应头都能正常显示总数(一般站点 15-40 之间)。
插件版本升级到 1.1.2。1 parent ebcb7a9 commit 0f147b5
2 files changed
Lines changed: 4 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1 | 1 | | |
2 | 2 | | |
3 | 3 | | |
4 | | - | |
| 4 | + | |
5 | 5 | | |
6 | 6 | | |
7 | 7 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
29 | 29 | | |
30 | 30 | | |
31 | 31 | | |
32 | | - | |
33 | 32 | | |
34 | 33 | | |
35 | 34 | | |
| |||
56 | 55 | | |
57 | 56 | | |
58 | 57 | | |
| 58 | + | |
| 59 | + | |
| 60 | + | |
59 | 61 | | |
60 | 62 | | |
61 | 63 | | |
| |||
0 commit comments