Chrome 扩展存储

Chrome 扩展支持两种存储,一种可以自动同步,叫 sync,限制较多;一种保存在本地,叫 local。

以前写的有问题,编辑下。

研究了半天,原来 Chrome 扩展不支持文件存储,只能使用 chrome.storage 保存持久化数据。

提供两种形式,一种可以在浏览器间自动同步,适用登录用户保存设置,比如微博的“眼不见心不烦”,chrome.storage.sync,提供一个 key 8K,最大512个 key,总数据量100K(即不可能512个 key 都装满)的存储。这个方式对读写频率也有限制,想想也好理解,比精要往 Google 的云同步嘛。

另外一种则更接近平时用的 localStorage,叫 chrome.storage.local。它的限制很少,只要总量不大于5M即可(可以通过设置 unlimitedStorage: true 来取消上限)。

使用的时候,需要在 manifest.json 里声明权限

    {
      "permissions": [
        "storage"
      ]
    }

这样的话就比较符合我的预期了,用户可以任意保存字幕到本地,太多了自己删掉就是,如果希望云同步就付费或者看广告。

诡异的Chrome插件事件机制

Chrome插件在content script里使用JQ广播事件,可能会无法在页面里侦听。换做原生的就没有问题。

最近尝试开发Chrome插件,自然使用JQ来当基础。结果遇到一个问题:

我使用“程序注入(Programmatic injection)”的方式执行代码,试图实现自动填写表单的功能。因为目标网页的表单比较智能,前面的选项会影响后面选项的内容,所以必须在val(value)之后广播change事件来触发后面表单内容的填充。

结果失败了。直接在浏览器里使用控制台运行代码,没有问题,所以代码本身应该正确;确认需要的JS文件已经一一加载。于是我开始了漫长而挫折的调试之路。多次失败之后,我打开《英雄无敌三》换换心情……玩了一会儿游戏意外退出了,而我灵机一动,会不会是JQ广播事件的问题?在控制台调试没有问题,但是在content script里就不行,很可能是chrome把两段代码放在彼此隔离的环境中运行导致的。于是我放弃直接$(selector).change(),改用原生的dispatchEvent,结果,运行成功!

于是我猜,应该是JQ和Chrome的插件机制稍有冲突。可能以后做插件的话,还是Closure Library好些吧。

PS:写插件的好处是不用考虑兼容性,朝着Chrome写就行了。