迁移至Manifest Version 3

[CodFrm]

阻碍

后台脚本/定时脚本

由于MV3将background修改为了service worker，该项修改直接导致了无法在background的sandbox中运行后台脚本，可能需要等待该提案实现：https://github.com/w3c/webextensions/issues/170，https://docs.google.com/document/d/1b-I-vXq2h7OFFmus78jZXIWcKilKJLKLeGplnY9wt7k/edit#heading=h.snjc0asv87ou，但啥时候实现，也不太清楚，实现之后也得有一段时间的过渡期

service worker中无法使用setTimeout等方法，直接导致cron包无法使用，但chrome也提出了chrome.alarms，实现起来可能比较麻烦

不支持sandbox的问题比较致命，但为了长期的发展，长痛不如短痛0.10.0将重构支持MV3，对于后台脚本的问题可能使用打开新窗口的方式暂时实现，等offscreen documents提案实现后再迁移（但也不确定能不能支持我们后台脚本的需求）

MV3还有不少有利的提案还在处理中，等到完全停止时也还有一段时间，并且完全停止后也还需要一段过渡时间，国内浏览器与其他厂商的态度也不一，脚本猫继续使用MV2进行开发，开发过程中注意MV3的某些特性吧（例如service worker）

油猴脚本

service worker中不支持URL.createObjectURL，可能会导致GM_xhr方法无法获取二进制之类的内容

---

上述是准备重构时发现的问题，后续继续补充

---

计划时间:

脚本站后端重构完成之后,预计2023年中旬

[SSmJaE]

👍

[CodFrm]

mv3中的脚本猫后台脚本可行性验证： cookbook.offscreen-dom.zip

但是改动实在太多了，GM API也不确定能不能全实现，而且没动力，mv3重构计划等Google的ddl再说

[CodFrm]

firefox的mv3迁移指南：https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/

[CodFrm]

GM_xmlhttpRequest 实现问题：https://github.com/w3c/webextensions/issues/176

[Xdy1579883916]

你好, 此计划有新进展吗？

[CodFrm]

@Xdy1579883916 哈哈哈，最近没进展，方案调研了，准备写篇blog，再开始重构，但是最近沉迷其它事情去了

看公告，2025年6月会完全停掉mv2，还有点时间（

[Xdy1579883916]

@CodFrm 我对脚本管理插件很感兴趣，测试版油猴v3已经支持了，奈何不开源，暴力猴作者目前也在规划，偶然发现还有脚本猫。最近在读开发指南和一些主站的开发文档，只能说相见恨晚，不然高低少走些弯路：事件、fetch、xhr劫持，监听某一元素出现等等…

油中源码我粗略看了看，不得不说挺Java的

大佬，很期待你的blog，写了希望可以踢我一脚。

另外，新版本v3计划是v2和v3都兼容还是其他？

[CodFrm]

@Xdy1579883916 看了一下，没想到tampermonkey这么快已经迁移到了mv3，不过商城还没审核通过，我觉得mv3有些功能应该是无法实现了的，不知道tampermonkey会如何处理。

前几天写了一段，然后又去做其它事情了，等完全写完，我会发布在我的blog上，到时候和哥哥说，我也不保证完全正确，有些问题还得真正开发起来才知道，不过我也会记录下来。

油中源码是指的什么？不过我没有怎么使用过java😂

新版本的v3计划，是先发布beta版本（一直有，但是因为mv2的缘故无法上架商城），正式版本依旧v2，期间只对v2版本作一些bug修复，等v3版本稳定后正式版迁移到v3版本。

可以从更新日志中看到脚本猫的一个发版路线：https://docs.scriptcat.org/docs/change/

[Xdy1579883916]

@CodFrm hello 一之，我来催更了，这两周有新进展吗？

[CodFrm]

@Xdy1579883916 呜呜呜 没有进展，最近在忙其它的事情，GitHub都没几个提交呢😭

这周或者下周我努努力

[CodFrm]

@Xdy1579883916 https://blog.icodef.com/dev/frontend/scriptcat-mv3 不知道哥哥有什么其它想了解的和意见，后续就准备进入mv3的重构开发了

[Xdy1579883916]

@CodFrm 一之你好，最近我看到一个简约的脚本管理，有一点共鸣，发个repo给你看看。

您的文档我看了，有点疑问和建议：

1、我不太确定background是否可以操作dom

2、我司的插件升级v3比较早，xhr我们是该用fetch了，GM_xhr 的 blob数据可以考虑base64方案。 3、GM_xhr/GM_download 依赖的 URL.createObjectURL会有影响，可以放到 contentjs里面创建出链接再下载。在用户页面创建的链接背景脚本也是可以访问的。

4、文档是这么说的，但是创建动态规则，用完就删掉也行.....

5、我们目前是用的这个方案，确实不优雅，但是能实现，请求之前检查头信息，需要设置就创建一条动态规则，请求完了删掉规则

6、usercripts 可以看看我推荐你的那个repo，写的还不错。

一之，加油啊，这个任务很艰巨

[CodFrm]

简单看了一下这个eternity，还是有些参考价值的，和我一样使用的是dexie这个库管理数据库，不过他没有实现GM API，只是使用了chrome.userScripts API，可以运行脚本，https://github.com/BlackGlory/eternity/blob/master/src/utils/user-script.ts#L27。

我认为油猴脚本的精髓全在GM API上了，可以让脚本像浏览器扩展一样拥有更大的权限。

我不太确定background是否可以操作dom

可以的，background.html是可以的，js我不太记得了，目前后台脚本实现就是在background里放了一个iframe进行操作，或许我表达得有误解，只是操作background自身页面的DOM，通过这个DOM可以实现一些GM API的功能，设置剪贴板好像就是依赖的DOM

我司的插件升级v3比较早，xhr我们是该用fetch了，GM_xhr 的 blob数据可以考虑base64方案。

是只能使用fetch了，blob的数据目前我不知道能不能通过chrome.offscreen去实现，实在不行也只能base64了，但是这在数据较大的情况下，有很多问题

GM_xhr/GM_download 依赖的 URL.createObjectURL会有影响，可以放到 contentjs里面创建出链接再下载。在用户页面创建的链接背景脚本也是可以访问的。

放到 contentjs里面创建出链接再下载，问题是如何放，还是需要从扩展层传过去的，可能方案和上述的还是差不多

DNR的问题

条数限制那个，仅作吐槽。

header那些还真是这么搞么。。。太脏了，tampermonkey的我还没研究，希望能找到一个比较优雅点的办法

---

整体下来工作量很大，主要是很多方案又得重新设计，整个架构怕也得调整，望着头大😵‍💫

哥哥也是做这类型扩展的么？可以多多交流😋

[Xdy1579883916]

有这方面的兴趣啦，感觉这是个很棒的事情，有机会可以参与贡献☺️

[CodFrm]

@Xdy1579883916 可以，非常欢迎👏

[leic4u]

加油，期待 manifest v3 新版本🥰🥰🥰

[Xdy1579883916]

@CodFrm 我的插件搞完了，最近维护完，基本稳定了，来捧捧场

chrome webstore: https://chromewebstore.google.com/detail/%E9%A6%99%E8%8D%89%E5%B8%83%E4%B8%81%F0%9F%8C%BF%F0%9F%8D%AE/fencadnndhdeggodopebjgdfdlhcimfk

github: https://github.com/Xdy1579883916/vanilla-pudding

[CodFrm]

@Xdy1579883916 哥哥执行力真强，这么快就完成了

[Xdy1579883916]

@Xdy1579883916 哥哥执行力真强，这么快就完成了

不一样的 一之，我的插件没有 GM API，不需要处理复杂的脚本依赖存储、以及脚本安全相关

[CodFrm]

@Xdy1579883916 也很厉害了，我还没怎么动😭，近期还打算修修bug，mv2继续跑跑