(Firefox) MV3 需要非长注式设计

[cyfung1031]

不用 offscreen 更节能

• setClipboard -> 不使用document.execCommand，改以 navigator.clipboard.writeText
• openInTab -> 不使用window.open，改以 chrome.tabs.create
• xmlHttpRequest -> 在 service_worker 处理 xmlHttpRequest
• vscode-connect / vscodeConnect -> 为何要在offscreen 用这个

---

• runScript / stopScript / updateRunStatus -> 后台脚本不再以"长期驻守"为设计原则，改以
  • 一次触发 ( 启动后，处理一下，不超过20秒，然后处理完后结束 -- SW重启不触发）
  • 定期触发 ( 分为 5分钟 30分钟 1小时 24小时... 等Bucket alarm 定期触发脚本。使用 chrome.alarm)
    • CAT_trackInterval(5, ()=>....) 类似事件或callback触发机制
  • 连结触发 ( 以连结方式触发，使用 chrome.webNavigation )
    • onBeforeNavigate -> onCommitted -> [onDOMContentLoaded] -> onCompleted
    • CAT_onWebNavigate("beforeNavigate", ()=>....) 类似事件或callback触发机制
  • crontab ( 把corntab格式alarm化 )
    • 保留@crontab
    • 同时加入 CAT_trackCron("* * once * *", ()=>....)
  • SW重启 ( SW重启触发 )
    • CAT_onServiceWorkerRestarted("* * once * *", ()=>....)

---

• createObjectURL
  • requestExport, CAT_fileStorage
    • 用 createObjectURL.html?uuid=XXXXXX 来处理
    • createObjectURL.html 接收到 uuid 后，读取 service worker 的字串变数，接收后用 URL.createObjectURL 转换成 blob url, 再self-redirect到这个 blob url. redirect后blob url会立即消失
  • loadFavicon
    • 改掉现在的垃圾设计，储存成base64 dataURI

[CodFrm]

openInTab -> 不使用window.open，改以 chrome.tabs.create

是有一个选useOpen进行控制的，必须使用window.open，详情可以看：#178 chrome.tabs.create 无法触发某些本地协议

xmlHttpRequest -> 在 service_worker 处理 xmlHttpRequest

service_worker 中只能使用 fetch，无法使用 XMLHttpRequest

vscode-connect / vscodeConnect -> 为何要在offscreen 用这个

因为service worker是有存活时间的，ws可能会被断开

后台脚本不再以"长期驻守"为设计原则

后台脚本本来就是跑后台任务，肯定是要长期驻守的呀，难道再做一个像MV3一样的，控制存活时间，然后通过事件激活的东西，这不是找堵吗。

例如：前台投递一个任务，后台跑

createObjectURL.html

没太明白这个，是要再打开一个页面？

[cyfung1031]

openInTab -> 不使用window.open，改以 chrome.tabs.create

是有一个选useOpen进行控制的，必须使用window.open，详情可以看：#178 chrome.tabs.create 无法触发某些本地协议

不应如此。
不是用offscreen 做。是 chrome.tabs.create 打开 chrome-extension://xxx/redirect.html?url=xxxx 然后 redirect.html 直接 location.replace(url) 。连一次警告都不弹出

• < chrome.tabs.create 是上位API。可以控制前台后台打开，在哪个window里生成tab，tab的位置等。 用 window.open 不能设置这些，因为 window.open 是下位API。因此不会用下位API来取代上位API。这是跟 xhr {fetch: true} 的相反情况 >

• 見 弃掉 GM_openInTab {useOpen: true} #863

xmlHttpRequest -> 在 service_worker 处理 xmlHttpRequest

service_worker 中只能使用 fetch，无法使用 XMLHttpRequest

明白。Firefox可强制用 fetch: true. 因此问题不大。

• 見 重构 GM_xmlhttpRequest 的实作 #862 。

vscode-connect / vscodeConnect -> 为何要在offscreen 用这个

因为service worker是有存活时间的，ws可能会被断开

断开的问题是什么？
打开代码编辑器时重新连接不行吗
如果是代码编辑器的页面打开的状态，SW不会死

后台脚本不再以"长期驻守"为设计原则

后台脚本本来就是跑后台任务，肯定是要长期驻守的呀，难道再做一个像MV3一样的，控制存活时间，然后通过事件激活的东西，这不是找堵吗。

例如：前台投递一个任务，后台跑

如果你是指 valueChange等方式前台后台沟通，这也是event做法。不需要长期驻守 （ SW的valueChange可以触发注册了的 后台脚本执行）
长期驻守是指，例如定时脚本每天执行一次，长期驻守是一天运行offscreen 24小时，就是为了每24小时一次的执行
但如果用event机制，例如 chrome.alarms，只需要在每24小时执行一次，然后等一两分钟SW自然死
你可以想像成 nodeJS 的设计，全部采用事件触发
不需要一个连续执行的主程序
只是在MV3这个事件触发，会同时唤醒 SW，从而执行后台脚本

createObjectURL.html

没太明白这个，是要再打开一个页面？

跟 redirect.html 原理一样
只是参数是 随机uuidv4 然后由SW直接提供数据

---

因此Firefox没有offscreen 也能使用ScriptCat。不放弃ScriptCAT功能

[CodFrm]

断开的问题是什么？
打开代码编辑器时重新连接不行吗
如果是代码编辑器的页面打开的状态，SW不会死

需要持续的连接WebSocket，不是 代码编辑器的页面 和 代码编辑器的页面 没有关系，这里是vscode建立websocket server，扩展连接，接收vscode的脚本编辑信息进行更新，扩展不需要打开任何页面也可以更新脚本

如果你是指 valueChange等方式前台后台沟通，这也是event做法。不需要长期驻守 （ SW的valueChange可以触发注册了的 后台脚本执行）

那就需要编写调度逻辑，而且恢复后，一些定义的变量也会丢失，写MV3已经很痛苦了，现在写后台脚本也还要去考虑这事情，我接受不了

而且后台脚本需要使用 eval 执行，在service worker 和 offscreen 中会被扩展的CSP策略拦截，如果设定CSP策略又无法通过商店审核（现在后台脚本是运行在 offscreen->sandbox中）

跟 redirect.html 原理一样
只是参数是 随机uuidv4 然后由SW直接提供数据

如果脚本使用 fetch 之类的方法去读取数据，这只能读取到 redirect.html 页面的 html，而不是数据本身了，如果通过打开createObjectURL.html来创建 blob url返回给脚本，这又需要打开一个新页面

---

请保留offscreen，不要让事情变得复杂，如果Firefox永远的不支持offscreen，再来考虑上述方案作为一个兼容处理，或者直接砍掉（后台脚本可能就因为CSP问题无法处理了），现在，就让Firefox先待在MV2吧

[cyfung1031]

标题讲错了
应该是除了offscreen 以外也能相容 firefox 的 background page 设计

---

那就需要编写调度逻辑，而且恢复后，一些定义的变量也会丢失，写MV3已经很痛苦了，现在写后台脚本也还要去考虑这事情，我接受不了

请保留offscreen，不要让事情变得复杂，如果Firefox永远的不支持offscreen，再来考虑上述方案作为一个兼容处理，或者直接砍掉（后台脚本可能就因为CSP问题无法处理了），现在，就让Firefox先待在MV2吧

firefox 的 mv3 架构，是一个又像 service_worker 又像 offscreen 的东西
在 background page 可以使用 XMLHttpRequest 等东西
但又会像 service_worker 一样不活跃时关掉

所以应该一步步走向不用长驻的架构。
原因1: 浏览器不想扩充长驻浪费电力
原因2: 电脑休眠后还是会重启扩展 (用长驻架构的概念导致 cronjob 执行时间会出错。）
定时启动的后台脚本，或者是前台事件触发的后台脚本，理论上都可以保留

后台脚本需要使用 eval 执行

offscreen / firefox background page 可以使用 document.createElement("iframe")
把js代码转成 base64 / bloburl 然后由 iframe 执行

---

我觉得 google 日后会把 offscreen 改成 firefox 的 background page 设计，不会让它长驻记忆体
另外，放弃长注的设计，电脑从休眠醒来后，各脚本运行也能正常。

[CodFrm]

放弃非常驻的模式，一些定义的变量也会丢失，写MV3已经很痛苦了，现在写后台脚本也还要去考虑这事情，我接受不了，这样也提高了后台脚本的编写门槛

原因1: 浏览器不想扩充长驻浪费电力

关于这点，见仁见智吧，我不认为消耗了什么电力，常驻后台大部分时间都是空闲的，而且也没有前端页面的渲染，与其关注这点，还不如关闭几个空闲的tab。

另外对于 每次重启都需要重新跑一次初始化逻辑和常驻持久化内存哪个更节省资源 还有待商议，我记得 tophf 也吐槽过这点

原因2: 电脑休眠后还是会重启扩展 (用长驻架构的概念导致 cronjob 执行时间会出错。）

这点是因为休眠后 setTimeout/Interval 产生了延迟导致的，应该有解决方案，比如增加秒/分级别的定时器，检查一次是否到时间了，再执行一下，而不是完全依赖cronjob

另外对于 google 日后会把 offscreen 改成 firefox 的 background page 设计，不会让它长驻记忆体 这个再说吧，offscreen 本来也是因为砍掉了 background 的一个替代，又改成非常驻的，那也太混蛋了 w3c/webextensions#170