Logo

site iconrxliuli | 琉璃

Web 前端开发,在日本,喜欢自称「吾辈」让我很难受。。博客主要记录一些技术相关的东西
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

rxliuli | 琉璃 RSS 预览

当吾辈遇上 Firefox 中 9 年的陈年老 Bug

2025-02-16 20:31:07

背景

最近开发一个跨浏览器的扩展时,由于需要在 Content Script 中请求远端服务 API,在 Chrome 中没有遇到任何问题,但在 Firefox 中,它会在 Content Script 上应用网站的 CSP 规则。不幸的是,一些网站禁止在 Script 中请求它们不知道的 API 端点。

首先,这里出现了一个关键名词:CSP,又叫内容安全策略,主要是用来解决 XSS 的。基本上,它允许网站所有者通过服务端响应 Content-Security-Policy Header 来控制网站页面可以请求的 API 端点。例如下面这个规则仅允许请求 https://onlinebanking.jumbobank.com,其他 API 端点的请求都将被浏览器拒绝。

1
Content-Security-Policy: default-src https://onlinebanking.jumbobank.com

也就是说,你可以打开 Twitter,并在网站 Devtools Console 中执行 fetch('https://placehold.co/200'),然后就得到了一个 CSP 错误。

1739867422408.jpg

如果你将相同的代码放在扩展的 Content Script 中,然后在 Chrome 中测试扩展,一切正常。

1739869145008.jpg

而在 Firefox 中,嗯,你仍然会得到一个 CSP 错误。

1739869071702.jpg

如果你使用 Manifest V2,Firefox 则会正常放过,并且不会显示在 Network 中。吾辈甚至不想知道它做了什么。

1739869022575.jpg

经过一番调查,吾辈成功找到了相关的 issue,而它们均创建于 9 年前,最新的讨论甚至在 4 天前。检查下面两个 issue。

思路

那么,问题就在这儿,看起来也无法在短期内解决,如果想要让自己的扩展支持 Firefox,现在应该怎么办?
好吧,基本思路有 2 个:

  1. 绕过去,如果 Content Script 无法不能请求,为什么不放在 Background Script 中然后加一层转发呢?
  2. 如果网站的 CSP 有麻烦,为什么不使用 declarativeNetRequest/webRequestBlocking API 来修改或删除它们呢?

Content Script => Background Script 转发

首先需要在 Background Script 中定义接口,准备接受参数并转发请求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// src/entrypoints/background.ts
browser.runtime.onMessage.addListener(
(
message: {
type: 'fetch'
request: {
url: string
}
},
_sender,
sendResponse,
) => {
if (message.type === 'fetch') {
// 这儿看起来非常“怪异”,但没办法,Chrome 就是这样定义的
fetch(message.request.url)
.then((r) => r.blob())
.then((b) => sendResponse(b))
return true
}
},
)

同时必须在 manifest 中 声明正确的 host_permissions 权限,添加你要请求的域名。

1
2
3
{
"host_permissions": ["https://placehold.co/**"]
}

然后在 Content Script 中调用它。

1
2
3
4
5
6
7
8
9
10
// src/entrypoints/content.ts
console.log(
'Hello content.',
await browser.runtime.sendMessage({
type: 'fetch',
request: {
url: 'https://placehold.co/200',
},
}),
)

可以看到现在可以正常得到结果了,但这种方式的主要问题是与原始的 fetch 接口并不相同,上面实现了 blob 类型的请求接口,但并未完整支持 fetch 的所有功能。嗯,考虑到 Request/Response 都不是完全可以序列化的,这会有点麻烦。

1739871065758.jpg

使用 declarativeNetRequest API 来删除网站的 CSP 设置

接下来,将介绍一种非侵入式的方法,允许在不修改 Content Script 解决该问题,首先是 declarativeNetRequest API,由于 WebRequestBlocking API 被广泛的应用于广告拦截器中,直接导致了 Chrome Manifest V3 正式将其废弃,并推出了静态的 declarativeNetRequest API 替代(尽管远远不能完全替代),但对于解决当下的这个问题很有用,而且很简单

首先在 manifest 中声明权限,注意 host_permissions 需要包含你要处理的网站。

1
2
3
4
5
6
7
8
9
10
11
12
13
{
"host_permissions": ["https://x.com/**"],
"permissions": ["declarativeNetRequest"],
"declarative_net_request": {
"rule_resources": [
{
"id": "ruleset",
"enabled": true,
"path": "rules.json"
}
]
}
}

然后在 public 目录中添加一个 rules.json 文件,其中定义了要删除 x.com 上的 content-security-policy response header。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[
{
"id": 1,
"condition": {
"urlFilter": "https://x.com/**",
"excludedResourceTypes": []
},
"action": {
"type": "modifyHeaders",
"responseHeaders": [
{
"header": "content-security-policy",
"operation": "remove"
}
]
}
}
]

可以看到网站的 CSP 已经不复存在,可以看到浏览器也不会拦截你的请求了。但是,这种方法的主要问题是网站安全性受损,就这点而言,这不是一个好方法。

1739874302081.jpg
1739874464160.jpg

参考

一般而言,推荐使用 Background Script 转发请求,尽管它要编写更多的样板代码,吾辈也就此在 WXT 上问过框架作者,他似乎一般也会这样做。

参考: https://github.com/wxt-dev/wxt/discussions/1442#discussioncomment-12219769

将数据导入到 Cloudflare D1

2025-01-30 09:21:28

背景

最近在实现 Mass Block Twitter 插件的 Spam 账户共享黑名单时,使用了 Cloudflare D1 作为服务端的存储数据库。而之前在本地 indexedDB 中已经存储了一些数据,所以需要导入现有的数据到 Cloudflare D1 中。使用 IndexedDB Exporter 插件将 indexedDB 数据库导出为 JSON 数据,但如何导入仍然是个问题。

最初参考了 Cloudfalre D1 的官方文档,但它并没有如何导入 JSON 数据的指南,而且它也只能在 Cloudflare Worker 中使用,但它确实提供通过 wrangler 执行 SQL 的功能,所以重要的是如何从 JSON 得到 SQL。

尝试

直接从 JSON 生成 Insert SQL

最初看起来这很简单,既然已经有了 JSON 数据,从 JSON 数据生成 SQL 字符串似乎并不难,只需要一些简单的字符串拼接即可。但实际上比想象中的麻烦,主要是 SQL 中有许多转义很烦人,边界情况似乎很多,JSON.stringify 生成的字符串在 SQL 中有错误的语法。

例如

  • " 双引号
  • ' 单引号
  • \n 换行
  • 可能的 SQL 注入
  • 其他。。。

虽然也调研过一些现有的 npm 包,例如 json-sql-builder2,但它似乎并不支持生成在单个 SQL 中插入多行的功能,因此一开始并为考虑。而且它生成的结果如下,看起来是给代码用的,而非直接可以执行的 SQL 文件。

1
2
3
4
{
"sql": "INSERT INTO people (first_name, last_name, age) VALUES (?, ?, ?)",
"values": ["John", "Doe", 40]
}

调用 Rest API

在生成的 SQL 一直出现语法错误之后,一度尝试过直接在 Worker 中实现一个 API 用来做这件事,直到在 wrangler dev 在本地测试发现效率很低后放弃了,实现 API 本身反而并不复杂。

导入到 sqlite 然后 dump 出 Insert SQL

最后还是回归到生成 SQL 的方案上,基本流程如下

  1. 从 JSON 生成 CSV
  2. 使用 sqlite3 导入 CSV 到本地 .sqlite 文件
  3. 使用 sqlite3 dump 数据到 .sql 文件
  4. 使用 wrangler cli 执行 .sql 文件导入数据
1
2
3
4
5
6
7
8
9
10
11
12
sqlite3 db.sqlite < migrations/0001_init.sql # 初始化一个 sqlite 数据库

vite-node 0002_import.ts # 生成需要的 csv 文件

sqlite3 db.sqlite <<EOF
.mode csv
.import users.csv Tweet
EOF # 导入 csv 到 sqlite 中

sqlite3 db.sqlite .dump > db.sql # 导出数据到 sql 文件
# ⚠️ 注意,导出数据后需要进行一些必要的编辑,删除创建 table 和 index 的语句,仅保留正确的 insert into 语句
npx wrangler d1 execute mass-block-twitter --local --file=migrations/db.sql # 执行 sql 文件导入数据,修改 --local 为 --remote 在远端执行操作
0002_import.ts 的具体实现
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
import _data from './assets/mass-db_exported_data.json'
import { writeFile } from 'node:fs/promises'
import path from 'node:path'
import { Parser } from '@json2csv/plainjs'
import { tweetSchema, userSchema } from '../lib/request'
import { Tweet, User } from '@prisma/client'

const data = _data as {
tweets: (typeof tweetSchema._type & {
user_id: string
updated_at: string
})[]
users: (typeof userSchema._type & {
updated_at: string
})[]
}

const list: User[] = data.users.map(
(it) =>
({
id: it.id,
screenName: it.screen_name,
name: it.name,
description: it.description ?? null,
profileImageUrl: it.profile_image_url ?? null,
accountCreatedAt: it.created_at ? new Date(it.created_at) : null,
spamReportCount: 0,
createdAt: new Date(it.updated_at!),
updatedAt: new Date(it.updated_at!),
} satisfies User),
)
const parser = new Parser({
fields: [
'id',
'screenName',
'name',
'description',
'profileImageUrl',
'accountCreatedAt',
'spamReportCount',
'createdAt',
'updatedAt',
],
header: false,
})
const csv = parser.parse(list)
await writeFile(path.resolve(__dirname, 'users.csv'), csv)

总结

Cloudflare D1 是一个不错的数据库,基本在 Web 场景中是完全可用的,而且与 Worker 一起使用时也无需关注 Worker 执行的区域与数据库所在的区域可能不一致的问题。而关于这次的数据导入的麻烦,如果已经熟悉 D1 或数据库的话,可能 10 分钟就搞定了,还是太久不碰数据库和后端生疏了。

在 Chrome 插件中拦截网络请求

2025-01-02 22:58:59

动机

在实现 Chrome 插件 Mass Block Twitter 时,需要批量屏蔽 twitter spam 用户,而 twitter 的请求 header 包含的 auth 信息似乎是通过 js 动态生成的,所以考虑到与其检查 twitter 的 auth 信息是如何生成的,还不如拦截现有的网络请求,记录使用的所有 header,然后在调用 /i/api/1.1/blocks/create.json 接口时直接使用现成的 headers。因而出现了拦截 xhr 的需求,之前也遇到过需要拦截 fetch 请求的情况,而目前现有的库并不能满足需要。

1736254864238.jpg

已经调查的库包括

  • mswjs: 一个 mock 库,可以拦截 xhr/fetch 请求,但是需要使用 service worker,而这对于 Chrome 插件的 Content Script 来说是不可能的。
  • xhook: 一个拦截库,可以拦截 xhr 请求,但无法拦截 fetch 请求,而且最后一个版本是两年前,似乎不再有人维护了

因此,吾辈打算自己实现一个。

设计

首先,吾辈思考了自己的需求

  1. 拦截 fetch/xhr 请求
  2. 支持修改 request url 以实现代理请求
  3. 支持调用原始请求并修改 response
  4. 支持 response sse 流式响应

确定了需求之后吾辈开始尝试设计 API,由于之前使用过非常优秀的 Web 框架 hono,所以吾辈希望 API 能够尽可能的简单,就像 hono 的 Middleware 那样。

下面借用 hono 官方的 Middleware 的洋葱图 [1]

1736247259291.jpg

例如下面使用了两个 Middleware

1
2
3
4
5
6
7
8
9
10
11
app
.use(async (c, next) => {
console.log('middleware 1 before')
await next()
console.log('middleware 1 after')
})
.use(async (c, next) => {
console.log('middleware 2 before')
await next()
console.log('middleware 2 after')
})

实际运行结果将会如下,因为最早注册的 Middleware 将在“洋葱”的最外层,在请求处理开始时最先执行,在请求完成后最后执行。

1
2
3
4
5
middleware 1 before
middleware 2 before
// 实际处理请求...
middleware 2 after
middleware 1 after

实现

接下来就涉及到具体实现 fetch/xhr 的请求拦截了,这里不会给出完整的实现代码,而是更多给出实现思路,最后将会链接到实际的 GitHub 仓库。

fetch

首先说 fetch,它的拦截还是比较简单的,因为 fetch 本身只涉及到一个函数,而且输入与输出比较简单。

先看一个简单的 fetch 使用示例

1
2
3
fetch('https://api.github.com/users/rxliuli')
.then((res) => res.json())
.then((data) => console.log(data))

基本思路就是重写 globalThis.fetch,然后使用自定的实现运行 middlewares,并在合适的时机调用原始的 fetch。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
function interceptFetch(...middlewares: Middleware[]) {
const pureFetch = globalThis.fetch
globalThis.fetch = async (input, init) => {
// 构造一个 Context,包含 request 和 response
const c: Context = {
req: new Request(input, init),
res: new Response(),
type: 'fetch',
}
// 运行 middlewares,由于处理原始请求需要在“洋葱”最内层运行,所以处理原始请求实现为一个 middleware
await handleRequest(c, [
...middlewares,
async (context) => {
context.res = await pureFetch(c.req)
},
])
// 返回处理后的 response
return c.res
}
}

// 以洋葱模型运行所有的 middlewares
async function handleRequest(context: Context, middlewares: Middleware[]) {
const compose = (i: number): Promise<void> => {
if (i >= middlewares.length) {
return Promise.resolve()
}
return middlewares[i](context, () => compose(i + 1)) as Promise<void>
}
await compose(0)
}

现在,可以简单的拦截所有的 fetch 请求了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
interceptFetch(
async (context, next) => {
console.log('fetch interceptor 1')
await next()
console.log('fetch interceptor 1 after')
},
async (context, next) => {
console.log('fetch interceptor 2')
await next()
console.log('fetch interceptor 2 after')
},
)
fetch('https://api.github.com/users/rxliuli')
.then((res) => res.json())
.then((data) => console.log(data))
// 输出
// fetch interceptor 1
// fetch interceptor 2
// fetch interceptor 1 after
// fetch interceptor 2 after
// {
// "login": "rxliuli",
// "id": 24560368,
// "node_id": "MDQ6VXNlcjI0NTYwMzY4",
// "avatar_url": "https://avatars.githubusercontent.com/u/24560368?v=4",
// ...
// }

有人可能会有疑问,这与 hono 的 Middleware API 也不一样啊?别着急,API 在最外层包一下就好了,先实现关键的请求拦截部分。

xhr

接下来是 xhr,它与 fetch 非常不同,先看一个简单的 xhr 使用示例

1
2
3
4
5
6
const xhr = new XMLHttpRequest()
xhr.open('GET', 'https://api.github.com/users/rxliuli')
xhr.onload = () => {
console.log(xhr.responseText)
}
xhr.send()

可以看出,xhr 涉及到多个方法,例如 open/onload/send 等等,所以需要重写多个方法。而且由于 middlewares 只应该运行一次,而 xhr 的 method/url 与 body 是分步传递的,所以在实际调用 send 之前,都不能调用原始 xhr 的方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
function interceptXhr(...middlewares: Middleware[]) {
const PureXhr = XMLHttpRequest
XMLHttpRequest = class extends PureXhr {
#method: string = ''
#url: string | URL = ''
#body?: Document | XMLHttpRequestBodyInit | null
// 重写 open 方法,在调用原始 open 方法之后,仅记录参数
open(method: string, url: string) {
this.#method = method
this.#url = url
}
// 保存所有事件监听器
#listeners: [
string,
(this: XMLHttpRequest, ev: ProgressEvent) => any,
boolean,
][] = []
set onload(callback: (this: XMLHttpRequest, ev: ProgressEvent) => any) {
this.#listeners.push(['load', callback, false])
}
// 重写 send 方法,在调用原始 send 方法之前,运行 middlewares
async send(body?: Document | XMLHttpRequestBodyInit | null) {
this.#body = body
const c: Context = {
req: new Request(this.#url, {
method: this.#method,
body: this.#body as any,
}),
res: new Response(),
type: 'xhr',
}
// 绑定注册的事件监听器
this.#listeners.forEach(([type, listener, once]) => {
super.addEventListener.apply(this, [type, listener as any, once])
})
// 运行 middlewares
await handleRequest(c, [
...middlewares,
async (c) => {
super.addEventListener('load', () => {
// 设置响应
c.res = new Response(this.responseText, { status: this.status })
})
super.send.apply(this, [c.req.body as any])
},
])
}
}
}

现在实现了一个非常基本的 xhr 拦截器,可以记录和修改 request 的 method/url/body,还能记录 response 的 status/body。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
interceptXhr(async (c, next) => {
console.log('method', c.req.method, 'url', c.req.url)
await next()
console.log('json', await c.res.clone().json())
})
const xhr = new XMLHttpRequest()
xhr.open('GET', 'https://api.github.com/users/rxliuli')
xhr.onload = () => {
console.log(xhr.responseText)
}
xhr.send()
// 输出
// method GET url https://api.github.com/users/rxliuli
// json {
// "login": "rxliuli",
// "id": 24560368,
// "node_id": "MDQ6VXNlcjI0NTYwMzY4",
// "avatar_url": "https://avatars.githubusercontent.com/u/24560368?v=4",
// ...
// }

当然,目前 xhr 的实现还非常简陋,没有记录所有 onload/onerror/onreadystatechange 事件,也没有记录所有 header,更不能修改 response。但作为一个演示,整体的实现思路已经出来了。

更多

目前已经实现了完整的 fetch/xhr 拦截器,发布至 npm 上的 @rxliuli/vista 包中,欢迎使用。

2024,不上班的第一年

2025-01-02 22:54:49

自从 2023 年底前往日本之后,吾辈就没有再上过一天班。在日本的时候,基本没有考虑过打零工。而回国之后,则开始了间隔性的旅行和躺平。回国的主要目标之一成为独立开发者仍未实现,即使尝试过开发一些东西,但都没有找到正确的途径。而且严重缺乏输入,现实几乎没有人可以长期交流,这是一个问题,可能一直都是一个问题。

时间线回顾

1~3 月: 在日本留学,在关西地区旅行,也前往东京进行过短期旅行
4~6 月: 完成了全国旅行,虽然途径磕磕绊绊,但最终吾辈还是做到了
7 月: 在阳江租房长住,但实际上几乎没有出门玩过,月底回到老家两周
8 月: 在阳江躺平,月底终于前往了当地的海陵岛,(服务)体验一般
9 月: 月初终于继续旅行,历经衡山长沙南京镇江之后,遇到台风匆匆赶回
10 月: 前往新一家暂住一周多,之后前往云南昆明大理等地,10 月下旬返回
11~12 月: 完全在阳江躺平,并陷入了严重失调的日常生活

1736650224627.jpg

自问自答

  1. 你今年最大的成就是什么 – 第一次尝试并完成了全国旅行
  2. 你今年最大的失败是什么 – 没有找到独立开发的正确途径
  3. 你有没有遵守年初时和自己许下的约定 – 几乎没有,作息规律和独立开发都是
  4. 今年的哪个或哪些日子会铭刻在你的记忆中,为什么 – 在新疆抱团旅行的时光,和其他人一起旅行的感觉很好
  5. 明年你想要获得哪些你今年没有的东西 – 在苏州长住,独立开发/或者其他什么获得收入(无论多少)、作息规律、开始晨跑
  6. 今年你学到了什么宝贵的人生经验 – 在选择有限的情况下不要匆匆决定,它会限制视野,而且很可能不是正确的
  7. 有什么是你想要且得到了的 – 没有约束的生活
  8. 是什么让你保持理智 – Twitter/Ao3,有时候开发一些插件或应用在 Twitter 发布,以及入坑 Worm 系列,这是自 PMMM 之后花了最多时间的小说系列
  9. 在你新认识的人之中,谁是最好的 – 新一,很厉害的一位开发者,不仅尝试创业,还逐渐步入正轨,几乎就是吾辈期望达到的一种状态。而且人也特别好,允许吾辈在他那里借住
  10. 你想念哪些人 – 曾经的老师。尽管去过他家里很多次,一起吃过饭出去玩,但现在逐渐渐行渐远,平时也不再能说得上话了

总结

独立开发

2024 年,主要还是开发了各种各样的 Chrome 插件,目前还在维护的大概有十几个,但大多数都反响平平,而且始终没有考虑过盈利问题,也许是因为毕竟没有盈利的压力。其中花费了大量时间开发的 PhotoShare 和 NovaChat,则没有真正完成和推广过。也许随着旅程的继续,吾辈将寻找到真正通往胜利的道路
下面是 2024 维护过的东西

  • Mass Block Twitter: 年尾 Twitter 又开始妖魔横行,所以当即开发了一个插件来批量屏蔽各种币圈 Spam 账号
  • Bilibili Markdown: 发布同人小说到 b 站专栏时粘贴 Markdown 到 Quill 富文本编辑器
  • Redirector: 根据规则重定向网页,避免外链跳转或者其他需求
  • ZenFS Viewer: 开发者工具,ZenFS 的可视化集成
  • TypeScript Console: 开发者工具,在 Devtools 中使用 TypeScript
  • Google Search Console - Bulk Index Cleaner: Google Search Console 的索引批量清理工具
  • Clean Twitter: 还原干净的 Twitter 体验,清理 UI 上的各种元素
  • NovaChat: 一个支持插件、本地优先的 ChatUI。时隔两年再次尝试写 ChatUI,想要的插件系统只在 Poe 中见过,但它不是本地优先的

《Worm》

Worm 是一部网络小说,也是自魔法少女小圆之后又一部真正热爱的作品。同样是从同人小说开始入坑,看完可能上百本同人小说,仅浏览记录就有 4257 个,而相同时间内 Twitter 浏览记录仅有 205 个,这确实说明了吾辈花费了多少时间。小说中的泰勒面对了各种困境和挑战,不得不因正确的理由做错事,从一个备受欺凌、想成为超级英雄的女高中生,到成为接管城市的超级反派,最终拯救了世界却被人害怕而招致死亡。至少可以说,“升级女王”是一个让人尊敬的女孩,上一个让吾辈有这种感觉的还是一之濑琴美,以及更早的樱小路露娜,她们都曾经历了痛苦但都成功地克服了它们,或许这正是吾辈喜欢她们的理由。

下面是作品简介:
主角是一个名叫泰勒・赫伯特的女高中生,是个失去母亲的黑发褐肤、性格阴郁的女孩。她在学校遭受霸凌,唯一支撑她活下去的希望是:不久前她经历了 “触发事件”,获得了控制昆虫的超能力。如果她能顺利参加“监护者计划”,就能成为一个真正的超级英雄,为她那悲惨的人生增添一些意义…

推荐从 TV Tropes 寻找喜欢的 Worm 同人小说,就英文圈子而言,它大概有 15k 本同人小说,是 Madoka 英文同人圈的 3~4 倍。

2025

2025 年吾辈仍然不会考虑长期工作,目前仍然有时间和成本去尝试做一些不一样的事情,如果八爷独立开发之路步入正轨花了 3 年,那么吾辈也可以花费同样多的时间。下面立一些 2025 的 Flag,将每个月都 check 一下

  • 通过独立开发获得收入,不管它是多么少,必须开始接入 Paddle 等支付系统
  • 作息规律,这是自工作之后一直想做而未成之事
  • 开始晨跑,从 Worm 中得到的想法,泰勒经历了更糟糕的事情,她通过晨跑来改善心情
  • 寻找新的兴趣,目前动画已经几乎不再维持,沉迷同人小说是个糟糕的兴趣,户外徒步和摄影还不错但还未长期维持过

在 Chrome 插件中将 ArrayBuffer 从网页传递到 Devtools Panel

2024-11-13 02:52:02

背景

最近使用了 ZenFS 在浏览器中模拟文件系统,以在浏览器中像使用 node fs api 一样存储一些文件。但想要可视化的检查当前存储的文件时,却没有一个可以直观的工具来完成。所以就创建了一个 Chrome Devtools Extension ZenFS Viewer,以实现这个目标。在此过程中就遇到了如何传递 ArrayBuffer 从网页到 devtools panel 线程的问题,一些尝试如下。

browser.devtools.inspectedWindow.eval

首先尝试了最简单的方法,browser.devtools.inspectedWindow.eval 可以在网页执行任意代码并得到结果,例如

1
browser.devtools.inspectedWindow.eval(`__zenfs__.readdir('/')`)

然而 inspectedWindow.eval 并不支持 Promise 返回值,例如下面的表达式无法得到 Promise 结果

1
browser.devtools.inspectedWindow.eval(`await __zenfs__.promises.readdir('/')`)

同样的,也无法支持 ArrayBuffer。所以这个显而易见的 API 被放弃了。

1
2
3
browser.devtools.inspectedWindow.eval(
`await __zenfs__.promises.readFile('/test.png')`,
)

chrome.runtime.sendMessage

接下来就是思想体操的时候了,一开始考虑的方案就是通过 devtools panel => background script => content-script(isolation) => content-script(main) 进行中转通信,以此在 devtools panel 中调用网页的全局变量并传递和获取 ArrayBuffer 的响应。大概示意图如下

before.excalidraw.svg

然而在使用 chrome.runtime.sendMessage 时也遇到了和 inspectedWindow.eval 类似的问题,无法传递 ArrayBuffer,仅支持 JSON Value。当然可以序列化 ArrayBuffer 为 JSON,但在传输视频之类的大型数据时并不现实。

解决

之后经过一些搜索和思考,找到了一种方法可以绕道 chrome.runtime.message,因为注入的 iframe 和 devtools panel 同源,所以可以使用 BroadcastChannel 通信,而 iframe 和注入的 content-script(main world) 之间尽管不同源,但仍然可以通过 postMessage/onMessage 来通信,并且两者都支持传递 ArrayBuffer,这样便可绕道成功。

after.excalidraw.svg

Content-Script <=> Iframe

网页与注入的 iframe 之间,通信可以使用基本的 postMessage/onMessage 实现,为了减少冗余代码,这里使用 comlink 来实现。

先看看注入的 content-script,它主要是负责对 iframe 暴露一些 API 的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// entrypoints/main-content.ts
import { expose, windowEndpoint } from 'comlink'

export default defineUnlistedScript(() => {
const map = new Map<string, ArrayBuffer>()

interface IFS {
readFile: (path: string) => Promise<ArrayBuffer>
writeFile: (path: string, data: ArrayBuffer) => Promise<void>
readdir: (path: string) => Promise<string[]>
}

expose(
{
readFile: async (path: string) => {
return map.get(path) || new Uint8Array([1, 2, 3]).buffer
},
writeFile: async (path: string, data: ArrayBuffer) => {
map.set(path, data)
},
readdir: async (path: string) => {
return Array.from(map.keys()).filter((p) => p.startsWith(path))
},
} as IFS,
windowEndpoint(
(document.querySelector('#inject-iframe')! as HTMLIFrameElement)
.contentWindow!,
),
)
console.log('main-content')
})

而在 iframe 中,则需要转发所有来自 BroadcastChannel 的请求通过 postMessage 传递到上层注入的 content-script 中,其中在每次传递 ArrayBuffer 时都需要使用 transfer 来转移对象到不同线程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// entrypoints/iframe/main.ts
import { expose, transfer, windowEndpoint, wrap } from 'comlink'

interface IFS {
readFile: (path: string) => Promise<ArrayBuffer>
writeFile: (path: string, data: ArrayBuffer) => Promise<void>
readdir: (path: string) => Promise<string[]>
}

async function main() {
const tabId = (await browser.tabs.getCurrent())!.id
if (!tabId) {
return
}
const ipc = wrap<IFS>(windowEndpoint(globalThis.parent))
const bc = new BroadcastChannel(
`${browser.runtime.getManifest().name}-iframe-${tabId}`,
)
expose(
{
readFile: async (path: string) => {
const r = await ipc.readFile(path)
// 将 ArrayBuffer 通过 transfer 传递回 devtools-panel 中
return transfer(r, [r])
},
writeFile: async (path: string, data: ArrayBuffer) => {
// 将 ArrayBuffer 通过 transfer 传递到 content-script 中
await ipc.writeFile(path, transfer(data, [data]))
},
readdir: async (path: string) => {
console.log('readdir', path)
return await ipc.readdir(path)
},
} as IFS,
bc,
)

console.log('iframe main')
}

main()

Iframe <=> Devtools

而在 Devtools 中,要做的事情有一点点多 🤏。首先需要注入两个 content-script,而其中 isolation-content.js 是用来创建 iframe 的 content-script。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// entrypoints/devtools-panel/main.ts
import { PublicPath } from 'wxt/browser'

async function injectScript() {
const includeIframe = await new Promise((resolve) => {
browser.devtools.inspectedWindow.eval(
`!!document.querySelector('#inject-iframe')`,
(result) => {
resolve(result)
},
)
})
if (includeIframe) {
return
}
const tabId = browser.devtools.inspectedWindow.tabId
if (!tabId) {
return
}
await browser.scripting.executeScript({
target: { tabId },
files: ['/isolation-content.js' as PublicPath],
world: 'ISOLATED',
})
await browser.scripting.executeScript({
target: { tabId },
files: ['/main-content.js' as PublicPath],
world: 'MAIN',
})
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// entrypoints/isolation-content.ts
function createIframeUi() {
const wrapper = document.createElement('div')
wrapper.style.height = '0'
wrapper.style.width = '0'
const ifr = document.createElement('iframe')
wrapper.appendChild(ifr)
ifr.src = browser.runtime.getURL('/iframe.html')
ifr.style.width = '0'
ifr.style.height = '0'
ifr.style.zIndex = '-9999'
ifr.style.border = 'none'
ifr.id = 'inject-iframe'
document.body.appendChild(wrapper)
return ifr
}

export default defineUnlistedScript(() => {
console.log('isolation-content', createIframeUi())
})

接下来就可以在 devtools-panel 中获取数据了,由于 iframe 的注入完成的时机并不能确定,所以需要加个简单的通知机制。

1
2
3
4
5
6
7
8
9
10
11
12
// entrypoints/iframe/main.ts
import { wrap } from 'comlink'

async function main() {
// Other code...
console.log('iframe main')
await wrap<{
onReady: () => void
}>(bc).onReady()
}

main()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// entrypoints/devtools-panel/main.ts
async function main() {
await injectScript()
interface IFS {
readFile: (path: string) => Promise<ArrayBuffer>
writeFile: (path: string, data: ArrayBuffer) => Promise<void>
readdir: (path: string) => Promise<string[]>
}
const tabId = browser.devtools.inspectedWindow.tabId
if (!tabId) {
return
}
const bc = new BroadcastChannel(
`${browser.runtime.getManifest().name}-iframe-${tabId}`,
)
await new Promise<void>((resolve) => expose({ onReady: resolve }, bc))
console.log('onReady')
// Test code...
const ipc = wrap<IFS>(bc)
const r = await ipc.readdir('/')
console.log(r)
const data = new Uint8Array([1, 2, 3]).buffer
await ipc.writeFile('/test.txt', transfer(data, [data]))
const r2 = await ipc.readFile('/test.txt')
console.log(r2)
}

main()

完整代码参考: https://github.com/rxliuli/devtools-webpage-message-demo

总结

至今为止,仍然没有简单的方法来支持 Devtools Extension 与 Webpage 之间的通信来替代 inspectedWindow.eval,确实是有点神奇。