这是一个创建于 917 天前的主题，其中的信息可能已经有所发展或是发生改变。
搜索了以下，发现没人来吐槽？我是忍不住了...那我对没写过扩展的人从头简单讲一讲.
V3 引入了 Service workers 但是又不是真正的 Service workers🙄
Chrome 会每 5 分钟清理所有扩展 Service workers 也就是说，你的扩展最多存活 5 分钟，然后等待用户下次激活。激活方式？我也没看到文档有写只能摸索。
那如果我的工作没做完，要接上次的工作怎么办？ google 告诉你用 chrome.storage 类似 localstorage 一样的东西...这...
那如果一直要保持后台的扩展怎么办，很遗憾，目前没办法。广告拦截 Vimium SwitchyOmega 等等 如果升级到 V3 那就是死刑。
https://bugs.chromium.org/p/chromium/issues/detail?id=1271154 论坛里也是怨声载道
听说现在扩展商店页面已经停止提交 V2 版本的新扩展，Chrome 甚至表示 2023 年 1 月消灭所有 V2 扩展 https://developer.chrome.com/blog/mv2-transition/
为了对抗随机的清理事件，出现了很多“肮脏的手段”
https://stackoverflow.com/questions/66618136/persistent-service-worker-in-chrome-extension
甚至有的为了保持持续后台，做两个扩展然后相互唤醒。这种肮脏的手段说不定什么时候就失效了。
这些就算了 还有 V3 的 API 也极其难用，向用户页面注入脚本的 chrome.scripting 到了 102 版本内核以上 才支持在 document-start 里运行..
https://developer.chrome.com/docs/extensions/reference/scripting/#type-ScriptInjection
看参数 injectImmediately 浏览器要求。。
也就是说 在 102 版本之前 tampermonkey 能做到的事情，我一个扩展都做不到。哦..对..如果到了 V3 tampermonkey 也得死
还有个更严重的问题，webRequest 很多扩展特别是广告拦截的扩展这是核心 API ，它可以拦截浏览器访问某个页面..到了 V3 webRequest 不在具有拦截功能。
那怎么办...Chrome 给出了一个新东西 declarativeNetRequest
哎...首先 使用 declarativeNetRequest 创建规则是有数量限制的，3W 条. 光是 uBlock Origin 默认规则就不止 3W 条.
Service workers 里是不能操作 DOM 的 也就是说这些广告拦截如果不做出改变，只能有网址拦截功能 因为不能去分析 DOM
难怪 Firefox 对 V3 的兼容一推再推，出现了奇怪的操作，保持 V2 的前提下引入 V3 的 API🤣刚刚说的 chrome.scripting 在 firefox V2 里也能使用了。（需要 firefox 102 版以上）
附上一个来自 adguard 的吐槽
https://adguard.com/zh_cn/blog/manifestv3-timeline.html
如果 google 执意强推 V3 并不做出改变...firefox 会成为赢家
说起来我有点期待 2023 了
21 条回复 • 2022-10-02 16:29:14 +08:00
 |
1
Mr54 2022-06-23 18:27:13 +08:00
为什么会推这种看似是退步的协议
|
 |
2
Buges 2022-06-23 18:29:44 +08:00 via Android
> firefox 会成为赢家
当然不会，因为 Google 在推动这些之前，已经掌控了 Web 。 |
 |
3
krapnik 2022-06-23 18:35:24 +08:00
|
 |
4
miaomiao888 2022-06-23 18:38:33 +08:00
普通用户可能并不会在意加载了多少条规则，他们只管装了能过滤大多数广告就够了，所以 firefox 在这之中也捞不到什么好处。
|
 |
5
geekzhu 2022-06-23 19:21:07 +08:00  1
这么说起来有点期待 Firefox 了
|
 |
6
learningman 2022-06-23 19:54:11 +08:00
以后写规则还得加个权了，权低的没资格放到这三万条里边
|
 |
7
sweetcola 2022-06-23 20:44:50 +08:00
我再补充一些：
1. 因为 background 不是 html 了，没有 DOM ，不能使用 audio 和 video 来播放。 2. 重新加载扩展 /更新时如果仍然存在资源引用，service worker 会处于非活跃状态。 3. 无法在本地资源 link 扩展自带的 js, css 等文件。 4. service worker 中无法用 i18n 。 但不全是缺点，在用户隐私上面，MV3 绝对是一个提升。MV3 增加了很多在隐私方面的限制，非常重要的一点是不允许引用外部资源。扩展能做的东西太多了，接触了之后真是不敢安装没开源的扩展。虽然这应该是通过更严格的审核来解决，比如像 Firefox 那样必须要上传源代码。 |
 |
8
muzuiget 2022-06-23 20:58:05 +08:00
Manifest V3 的设计存在自相矛盾，那个 background 页面，API 变成 Service Worker ，跟普通网页的 SW 不同，就是会被随机杀死，然而很多扩展 API 都是要在 background 里运行的，比如那些响应特定事件的函数，所以弱智的地方来了：因为 background 是随时被杀死的，所以那些事件函数是无法运行的。因为每次重启 background ，都是重新运行一次代码，重新注册一次事件函数。
|
 |
9
kytrun 2022-06-23 21:14:34 +08:00
盲猜 Chrome 在 2023 年到来之时会作出部分妥协
 |
|
10
kytrun 2022-06-23 21:15:50 +08:00
Edge 是什么态度？能不能趁此机会……
|
 |
12
ChenYFan 2022-06-24 00:01:49 +08:00
1.虽然 sw 确实对网页加载提升巨大，但是强制要求插件也用 sw ，还有这么傻逼的杀死策略...谷歌强迫 v3 必须使用 sw 是可以算作 pwa 或者用户隐私的进化，然而最插件基本诉求都不理会.真要是这么搞就是自己慢性自杀.
2.虽然自唤醒很肮脏,和国内安卓应用自唤醒交易差不多恶心人,但是没有阴暗的压迫，怎么会有肮脏的滋生？ |
 |
13
gzlock 2022-06-24 00:11:12 +08:00
我说啊，如果 edge 继续 v2 扩展协议，市场份额妥妥的可以反杀 chrome
|
 |
14
dingwen07 2022-06-24 00:29:51 +08:00 via iPhone
谷歌下一步不会搞一个什么 API 给网页提供 Certificate Pinging 功能，完全阻止掉 AdGuard 桌面版这种 MITM 的过滤器吧……
|
 |
15
Yadomin 2022-06-24 00:43:44 +08:00
|
 |
16
thefack 2022-06-24 01:33:47 +08:00
V3 的 Service workers 确实不方便
过 15 秒还是 30 秒就会终结 Service workers ，但执行网络请求不受这个时间的限制。 可惜了需要等待多少秒才进行下一步的功能不好实现了，settimeout 这类函数超过这个秒数就用不了了。 |
 |
17
xifangczy OP @thefack 是的 不能使用 setinterval settimeout , 但是扩展有个 chrome.alarms API 可以定时任务，这也是自我唤醒的方法之一。
|
 |
18
lzgshsj 2022-06-24 15:50:59 +08:00
v3 真的是太要命了，现在自己写着玩的插件只能停在 v2 看（等）情（死）况了，到时候不知道关闭 chrome 更新能坚持多久
|
 |
19
caqiko 2022-06-28 11:42:11 +08:00
搭车问下，通过 chrome 扩展给部分域名下的页面添加一些 div ，然后填充信息，这个用什么技术最好？
我现在用的是 jquery 操作 DOM ，但是经常看到说 jquery 已经被淘汰了，不知道有没有更好的方案？ 不需要写一个完整的页面，基本全是在 content script 里面操作。这种场景，React / Vue 能用上吗？ |
|
20
xifangczy OP 1
@caqiko 为什么一定要上框架？只是一个 content script 操作 DOM 的话 原生已经很好用了，没必要去加载框架。
|
 |
21
lingyired 2022-10-02 16:29:14 +08:00 via Android
像之前那些定时检查邮件插件在 mv3 还有办法实现吗。
|
Select Language