标签： chrome extension

分类
扩展

Chrome 扩展大升级 Manifest V3：设计原则

Chrome 前阵子发布了 Chrome Extension Manifest V3 规范，算是为浏览器扩展开发的下一步明确了方向。虽然目前只在 Chrome 浏览器里有效，不过鉴于 Chrome 的统治级地位，相信只要不出大问题，将来肯定会成为 Browser Extension 规范——实际上，Browser Extension API 就约等于 Chrome Extension Manifest V2。

我最近一两年的工作大多围绕浏览器扩展展开，所以对这个规范很关注，近期也研读了不少，准备写几篇博客分享一下。这是第一篇，主要分享下 MV3 规范的设计原则。

1. 保护隐私

最初的浏览器扩展给了开发者非常大的自由，可以让浏览器扩展大大加强浏览器的能力，但是也会给普通用户带来大量数据外泄的风险。

新规范支持浏览器扩展在不需要特殊权限的时候先正常运行，有用到某个权限的时候，再向用户请求使用许可。另外，权限的授予也不再是永久的，避免长期授权可能导致的问题。

2. 保障安全

扩展要上商店，必须经过审核，很多功能可能没那么容易过审。于是很多应用开发者都会想方设法使用外部资源来绕开平台对应用的监管，这样做能带来更强大的功能，也会带来更大的隐患。比如我厂，Showman 必须用外部 JS 才能驱动网页；但如果是恶意开发者，他们可能会利用这点干坏事。

对于外部资源的使用，新规范采用了更严格的限制。V3 里，只能使用静态外部资源，比如图片视频等，外部脚本彻底不能跑了。这对我厂 Showman 是不利消息。

3. 提高性能

Chrome 的性能一直被人诟病，内存杀手的恶名背负已久。可能很多人不知道，其实 Chrome 扩展架构一直是个大问题。出于安全考虑，扩展里的 JS 会运行在很多不同环境下，比如 content script，background script，都会跑在独立的沙箱里，也就是说，哪怕你一个页面都不开，可能也有好几个扩展 background page/script 在悄悄运行，占用你的内存。

所以新版本也作出改进，强制限制只能使用一个 background script，而且这个 background script 必须以 service worker 形式来跑。保证浏览器扩展不会吞噬掉所有系统资源。

4. 追随统一的 Web 平台

以前为了提供更强大的功能，给扩展增添了很多专享 API，比如文件读写。如今 Web 平台不断发展，一些经过验证的 API 被吸纳到 Web 标准，一些步子太大的 API 被证明其实没啥用。总之，为了让降低开发者的心智负担，也让更多的代码可以一次开发导出运行，新规范会尽量向 Web 平台靠拢，减少专享 API，鼓励使用 Web API。

5. 改善功能

当然，说到底，大家之所以用浏览器扩展，还是因为它的功能比 Web 强。所以新版本还会继续探索新的可能性，让扩展平台更强大、功能更丰富，以便给用户带来更大的价值。

总结

MV2 已经过去了大约十年，确实有一些不合时宜之处，各个平台也逐步摸索了一些更好的策略，比如，权限和安全性的改进很明显是从 iOS、Android 学习而来。至于性能表现，我也很期待。

以上内容主要来自于我对新老 API 的理解和这篇官方介绍：Extensions platform vision – Chrome Developers。推荐阅读。

分类
分享

应用（直播）创意：弹幕收集器（BB酱）

BB酱 v0.1

2021-03-27 更新

经过近两周的开发，我已经用上了 BB酱 v0.1。目前支持以下功能：

  • 支持读取并上传弹幕
  • 按用户名搜索、筛选
  • 取特定时间段弹幕进行抽奖

在 B 站直播了一段时间，发现 B 站没有弹幕记录——其实斗鱼也没有。这里面的产品逻辑应该是：弹幕比评论更短、更情绪化、与视频内容关系更紧密，量也太大，独立的弹幕存在价值稀薄，单独做一个列表的性价比很低。

不过我觉得，对于主播来说，弹幕还是有一些价值的，尤其是我这种没什么人看的小主播，很多时候翻翻弹幕能找回很多继续播的动力。

所以我想做一个浏览器扩展，自动收集直播里的弹幕，然后保存起来。这样需要的时候我就能回看，或者搜索，野炊就经常用这个功能跟弹幕互怼。

另外，B 站的直播互动功能不强，连基础的弹幕投票和弹幕抽奖都不支持，也可以利用这个插件实现。

这个想法吸引我的还有几个点，我觉得很适合用来做直播：

  1. 足够简单，一次直播半个小时就能完成基本功能
  2. 涉及到的技术点也不少，比如 Chrome extension API、Vue 项目搭建、Mutation Observer、Serverless 等，展开讲能讲不少，不展开直接口播介绍一下也可以
  3. 做出来之后可以给其他主播用
分类
chrome

Chrome 扩展里实现 SSO

周五打算给客户发版，结果在这里卡了大半天，写篇博客记录下。

0. SSO 的实现

SSO，Single sign-on，单点登录，即统一处理用户登录、提供用户身份凭据的功能。使用 SSO，可以只维护一套用户体系，容易开发维护；对用户来说，只需要登录一次就能使用该开发商的全部产品，也很轻松方便。

一般来说，SSO 的流程是：

  1. 用户使用 A产品，域名是 pa.mydomain.com，登录服务（S）位于 login.mydomain.com
  2. 用户使用提供服务的 A产品，A产品需要登录，用户选择登录
  3. 来到登录服务，完成登录
  4. S服务将用户指回 A产品，返回的 URL 里包含一个 token
  5. A产品拿到 token，请求 S服务，验证 token，获取部分用户信息（比如邮箱，一般只用来展示
  6. A产品生成自己所需的身份凭据，并以此验证用户身份

我厂的产品也是这么实现的。

1. Chrome 扩展遇到的问题

本地调试一切正常，但是加载成扩展之后，从登录服务跳回扩展会遇到 ERR_BLOCKED_BY_CLIENT 错误，URL 也被重定向到 chrome://invalid/。我在这里卡了很久，主要是不知道该怎么定位问题和搜索答案。

后来经过反复尝试，我终于发现，只有从登录页面跳转回去插件页面的时候，即 location.href='chrome-extension://{id}/ui/index.html 的时候，才会报错，所以立刻换用 chrome extension href ERR_BLOCKED_BY_CLIENT 作为关键词，立刻找到了答案：redirect to chrome-extension:// results in ERR_BLOCKED_BY_CLIENT。

然后阅读文档：Manifest – Web Accessible Resources（可由 Web 访问的资源），得知需要在 manifest.json 里添加对应的配置：

{
  ...  "web_accessible_resources": [
    "ui/index.html"
  ],
  ...
}

添加后 SSO 就正常了。

2. 后记

不过我没想明白的是，这个配置意义何在？配置写在扩展里，防止 web 访问扩展里的文件，似乎并没有什么帮助，也没什么安全性的顾虑。也许是我还没遇到吧。

分类
chrome

让 Chrome API 支持 Promise

Chrome API 都是回调型，连续使用非常不方便，希望能改成 Promise 型。Chrome 本身不提供 promisify，不过可以自己写一个：

export default function promisify(original) {
  return function (...args) {
    return new Promise((resolve, reject) => {
      original(...args, (...results) => {
        if (chrome.runtime.lastError) {
          reject(chrome.runtime.lastError.message);
        } else {
          resolve(...results);
        }
      });
    });
  }
}

这里有几个注意事项：

  1. 参数使用 ...args 进行拆解和合并，方便调用
  2. 需要检查 runtime.lastError，不然出错的时候浏览器会报错，影响体验

使用的时候，我比较喜欢只修改需要使用的函数，不打算 promisify 全部函数，大概是这样：

import promisify from './index';

/* global chrome */

export const update = promisify(chrome.tabs.update);
export const remove = promisify(chrome.tabs.remove);
export const get = promisify(chrome.tabs.get);
// 我觉得 `close tab` 看起来更合理
export const close = remove;
// 封装一个 `goto` 的快捷方式
export const goto = function (tabId, url) {
  return update(tabId, {url});
}
// 全部导入，好处是简单，坏处是不方便 tree-shaking
import * as ChromeTabs from '../chrome-promisify/chrome.tabs';

ChromeTabs.goto(tabId, 'https://blog.meathill.com');

// 需要哪个导入哪个
import {goto} from '../chrome-promisify/chrome.tabs';

goto(tabId, 'https://github.com/meathill');
分类
chrome

Chrome 扩展存储

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

研究了半天，原来 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 插件 popup.html 长期打开

开发 Chrome 插件时，如果使用 popup.html，调试时反复审查元素很麻烦。此时可以用

chrome-extension://插件id/popup.html

在新标签页打开，就简单多了。

分类
js

诡异的Chrome插件事件机制

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

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

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

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

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