mainfest.json MV2 迁移 MV3 详细说明文档

6,223 阅读21分钟

前言

Manifest V3 是什么? 扩展都有清单文件 manifest.json , 文件内容中有 manifest_version 字段,该字段对应的 3 ,就表示使用 Manifest V3 版本。

MV3 中更看中安全,弃用了很多功能,比如执行远程的JS代码,在 chrome 91 + 之后,就不再支持 chrome.tabs.executeScript 。也就是想要发布到官方扩展程序上,就必须改代码了。所以正规开发,还是要学习改用 MV3 。

本文是对官方文档进行了一个机器翻译,同时会补充点知识点,还在更新中,标题后面有 🌹 的表示比较常用/重要。

Manifest V3 和 Manifest V2 有什么区别?

使用 MV3的扩展将在安全性、隐私性和性能方面得到增强; 它们还可以使用 MV3中采用的更现代的开放 Web 技术,比如 service workers 和 promises。

  • 改进用户可见性和控制
  • 允许用户修改授予扩展的主机权限 host permissions
  • 显示哪些项可以或希望访问当前页的扩展菜单
  • 一种新的用户数据访问方法
  • 不希望扩展对用户数据进行持久访问
  • 希望让用户临时授予权限,并且只在需要他们的上下文中授予权限。

具体的迁移: developer.chrome.com/docs/extens…

Manifest V3 概览

Manifest V3 的主要变化和特性。 发表于2020年11月9日,星期一

Manifest V3 (MV3) is a major step forward in steering towards our vision for the extensions platform. MV3 focuses on the three pillars of that vision: privacy, security, and performance, while preserving and improving our foundation of capability and webbiness.

Manifest V3(MV3)是指导我们实现扩展平台愿景的重要一步。MV3专注于这个愿景的三个支柱: 隐私、安全和性能,同时保持和改进我们的能力和网络性能的基础。

This article summarizes the features and major changes introduced by MV3. For help migrating Manifest V2 extensions to MV3, or to better understand the architectural impact of these changes, see also the MV3 migration guide.

本文总结了 MV3的特点和主要变化。要帮助将 Manifest V2扩展迁移到 MV3,或者更好地理解这些更改的体系结构影响,请参阅 MV3迁移指南。

Manifest V3 is available beginning with Chrome 88, and the Chrome Web Store begins accepting MV3 extensions in January 2021.

从 Chrome 88开始就可以使用 Manifest v 3,Chrome Web Store 从2021年1月开始接受 MV3扩展。

New features and changes will continue to be added to MV3, just as they have been in earlier manifest versions.

新特性和更改将继续添加到 MV3中,就像它们在早期的清单版本中一样。

Feature summary 特色摘要

There are a number of new features and functional changes for extensions using MV3:

使用 MV3扩展有一些新的特性和功能变化:

Each of these changes is summarized in the sections below.

以下各节概述了这些变化。

Major features 主要功能

This section introduces the most important and impactful features of MV3.

本节介绍 MV3最重要和最有影响力的特性。

Service workers 服务工作者

Manifest V3 replaces background pages with service workers.

Manifest V3用服务工作者替换后台页面。

Like their web page counterparts, extension service workers listen for and respond to events in order to enhance the end user's experience. For web service workers this typically means managing cache, preloading resources, and enabling offline web pages. While extension service workers can still do all of this, the extension package already contains a bundle of resources that can be accessed offline. As such, extension service workers tend to focus on reacting to relevant browser events exposed by Chrome's extensions APIs.

像他们的网页同行一样,推广服务人员倾听和响应事件,以提高最终用户的体验。对于 web 服务工作者来说,这通常意味着管理缓存、预加载资源和启用脱机 web 页面。虽然扩展服务工作人员仍然可以完成所有这些工作,但扩展包已经包含了可以离线访问的资源包。因此,扩展服务工作者倾向于专注于对 Chrome 扩展 api 所暴露的相关浏览器事件做出反应。

Network request modification 网络请求修改

The way that extensions can modify network requests is changing in MV3. There's a new declarativeNetRequest API which lets extensions modify and block network requests in a privacy-preserving and performant way. The essence of this API is:

扩展可以修改网络请求的方式在 MV3中正在改变。有一个新的 declarativeNetRequest API,允许扩展以保护隐私和高效的方式修改和阻止网络请求。这个 API 的本质是:

  • Rather than intercepting a request and modifying it procedurally, the extension asks Chrome to evaluate and modify requests on its behalf. 这个扩展并没有拦截请求并按照程序进行修改,而是让 Chrome 代表自己评估和修改请求
  • The extension declares a set of rules: patterns to match requests and actions to perform when matched. The browser then modifies network requests as defined by these rules. 扩展声明了一组规则: 模式来匹配请求和匹配时要执行的操作。然后浏览器修改这些规则定义的网络请求

Using this declarative approach dramatically reduces the need for persistent host permissions.

使用这种声明性方法可以显著减少对持久主机权限的需求。

Some extensions may still require broad host permissions for certain use cases (such as redirecting requests). See Conditional permissions and declarativeNetRequest for further details.

对于某些用例(例如重定向请求) ,某些扩展可能仍然需要广泛的主机权限。有关详细信息,请参阅条件权限和 declarativeNetRequest。

The blocking version of the webRequest API is restricted to force-installed extensions in MV3. This is because of issues with the blocking webRequest approach:

webRequest API 的阻塞版本仅限于 MV3中强制安装的扩展。这是因为阻塞的 webRequest 方法存在问题:

  • Privacy 隐私: This requires excessive access to user data, because extensions need to read each network request made for the user. : 这需要对用户数据的过度访问,因为扩展需要读取为用户提出的每个网络请求
  • Performance 工作表现: Serializing & deserializing data across multiple process hops & the C++/JS boundary adds up. : 跨多个进程跃点序列化和反序列化数据 & c + +/JS 边界相加
  • Compatibility 兼容性: Does not work well with event-based background execution as it requires the service worker to be running to handle every request. : 不能很好地处理基于事件的后台执行,因为它需要运行服务工作者来处理每个请求

This means that developers can implement many common use cases, such as content blocking functionality, without requiring any host permissions.

这意味着开发人员可以实现许多常见的用例,比如内容阻塞功能,而不需要任何主机权限。

Remotely hosted code 远程托管代码

A key security improvement in MV3 is that extensions can't load remote code like JavaScript or Wasm files. This lets us more reliably and efficiently review the safe behavior of extensions when they're submitted to the Chrome Web Store. Specifically, all logic must be included in the extension's package.

MV3中一个关键的安全改进是扩展不能加载远程代码,比如 JavaScript 或者 Wasm 文件。这让我们可以更可靠、更有效地检查扩展提交到 Chrome 网络商店时的安全行为。具体地说,所有逻辑都必须包含在扩展的包中。

Instead of remote code, we recommend the use of remote configuration files. See the migration guide for more about how to work with this change.

我们建议使用远程配置文件而不是远程代码。有关如何处理此更改的更多信息,请参见迁移指南。

🌹 Promises

MV3 为 promises 提供了一流的支持: 许多流行的 api 现在都支持 promises ,并且我们最终将使所有适当方法都支持 promises

您可以使用 promise 链式写法 ,以及 async/await。如果你为 API 方法提供回调,这将防止返回 promise 。因此,您可以推迟迁移的这一部分,直到准备好为止,或者立即开始使用 promises。

比如,官方 getstarted 示例的 popup.js 文件变化如下:

// V2
changeColor.onclick = function(element) {
  let color = element.target.value;
  chrome.tabs.query(
    {active: true, currentWindow: true},
    // 回调函数
    function(tabs) {
      chrome.tabs.executeScript(
        tabs[0].id,
        {code: 'document.body.style.backgroundColor = "' + color + '";'});
    }
  );
};
// V3
changeColor.addEventListener("click", async (element) => {
  let color = element.target.value;
  let [tab] = await chrome.tabs.query({ active: true, currentWindow: true });
  // 等待异步完成

  // chrome.tabs.executeScript 变成了 chrome.scripting.executeScript
  chrome.scripting.executeScript({
    target: { tabId: tab.id },
    function: setPageBackgroundColor(color),
  });
});

// 此函数将作为当前页中的内容脚本执行
function setPageBackgroundColor(color) {
  document.body.style.backgroundColor = color;
}

某些场景,如:事件监听器,仍然需要回调。

Other features 其他功能

There are a number of other changes introduced in MV3:

在 MV3中还引入了一些其他的变化:

  • Action API consolidation 行动 API 整合: The Browser Action and Page Action APIs are unified into a single Action API. 浏览器操作和页面操作 API 统一为一个单一的操作 API
  • Web accessible resources 网络可访问的资源: These resources are now available only to specified sites and extensions. : 这些资源现在只能用于指定的站点和扩展
  • Content security policy (CSP) 内容安全策略(CSP): You now specify separate CSP for different execution contexts in a single object, and certain policies are disallowed. : 您现在为单个对象中的不同执行上下文指定单独的 CSP,并且不允许某些策略
  • executeScript() changes executeScript ()更改: Extensions can no longer execute arbitrary strings, only script files and functions. This method is also migrating from the Tabs API to the new Scripting API. : 扩展不能再执行任意字符串,只能执行脚本文件和函数。此方法也正在从 Tabs API 迁移到新的 Scripting API

The following features will be added to MV3 soon:

MV3不久将增加以下特性:

  • Dynamic content scripts: 动态内容脚本: the new Scripting API lets extensions register and unregister content scripts at runtime. 新的脚本 API 允许扩展在运行时注册和取消注册内容脚本
  • New favicon API: 新图标 API: this new JavaScript API replaces "chrome://favicons" and gives developers a way to retrieve websites' favicons. 这个新的 JavaScript API 取代了“ chrome://favicon”,为开发者提供了一种检索网站图标的方法
  • In-memory storage: 内存存储: a new StorageArea on the Storage API that can be used to store values in memory across service worker restarts. Storage API 上的新 StorageArea,可用于在服务工作者重新启动时将值存储在内存中

Look for announcements of these and other MV3 features as they become available.

在这些特性和其他 MV3特性变得可用时,查看它们的公告。

Last updated: Monday, November 9, 2020 • Improve article

最后更新: 星期一,2020年11月9日•改进文章


迁移到 Manifest V3

developer.chrome.com/docs/extens…

让你朝着正确的方向前进。 发表于2020年11月9日,星期一

This guide provides developers with the information they need to begin migrating an extension from Manifest V2 to Manifest V3 (MV3). Some extensions will require very little change to make them MV3 compliant, while others will need to be redesigned to some degree. Developers experienced with MV2, and who are creating new MV3 extensions, may also find this helpful. For a quick reference guide see the migration checklist.

本指南为开发人员提供开始将扩展从 Manifest V2迁移到 Manifest V3(MV3)所需的信息。有些扩展只需要很少的修改就可以兼容 MV3,而有些扩展则需要重新设计。有 MV2经验的开发人员和正在创建新的 MV3扩展的开发人员可能也会发现这很有帮助。有关快速参考指南,请参阅迁移检查表。

Manifest V3 offers a number of improvements reflecting the aims of our platform vision.

Manifest V3提供了许多改进,反映了我们平台愿景的目标。

Feature summary 特色摘要

There are a number of new features and functional changes for extensions using MV3:

使用 MV3扩展有一些新的特性和功能变化:

For a fuller description of these changes, see the MV3 Overview.

有关这些更改的更全面描述,请参阅 MV3概述。

Updating the manifest.json file

To use the features of MV3, you need to first update your manifest file. Naturally, you'll change the manifest version to "3", but there are a number of other things you need to change in the manifest file: host permissions, content security policy, action declarations, and web-accessible resources.

要使用 MV3的特性,首先需要更新清单文件。当然,您会将清单版本更改为“3”,但是您需要在清单文件中更改许多其他内容: 主机权限、内容安全策略、操作声明和 web 可访问的资源。

Manifest version 清单版本

Changing the value of the manifest_version element is the key to upgrading your extension. This determines whether you're using the MV2 or MV3 feature set:

更改 manifest _ version 元素的值是升级扩展的关键。这决定了你是使用 MV2还是 MV3特性集:

// Manifest v2

"manifest_version": 2
// Manifest v3

"manifest_version": 3

🌹 Host permissions 主机权限

In MV3, you'll need to specify host permissions separately from other permissions:

在 MV3中,你需要分别指定主机权限和其他权限:

// Manifest v2
"permissions": [
  "tabs",
  "bookmarks",
  "http://www.blogger.com/",
],
"optional_permissions": [
  "*://*/*",
  "unlimitedStorage"
]
// Manifest v3
"permissions": [
  "tabs",
  "bookmarks"
],
"optional_permissions": [
  "unlimitedStorage"
],
"host_permissions": [
  "http://www.blogger.com/",
  "*://*/*"
],

Warning 警告

You do not have to declare content script match patterns in host_permissions in order to inject content scripts. However, they are treated as host permissions requests by the Chrome Web Store review process.

为了注入内容脚本,不必在 host_permissions 中声明内容脚本匹配模式。但是,它们被 chromewebstore 审查过程视为主机权限请求。

🌹 Content security policy 内容安全策略

An extension's content security policy (CSP) was specified in MV2 as a string; in MV3 it is an object with members representing alternative CSP contexts:

在 MV2中,扩展的内容安全策略(CSP)被指定为字符串; 在 MV3中,它是一个对象,其成员表示可选的 CSP 上下文:

// Manifest v2

"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'"
// Manifest v3

"content_security_policy": {
  "extension_pages": "...",
  "sandbox": "..."
}

extension_pages: This policy covers pages in your extension, including html files and service workers.

extension_pages: 此策略涵盖扩展中的页面,包括 html 文件和 service workers 。

These page types are served from the chrome-extension:// protocol. For instance, a page in your extension is chrome-extension://<extension-id>/foo.html.

这些页面类型来自 chrome-extension:// 协议 。 比如,你扩展程序中的一个页面 chrome-extension://<extension-id>/foo.html

sandbox: This policy covers any sandboxed extension pages that your extension uses.

sandbox: 此策略涵盖扩展使用的所有沙盒扩展页面

In addition, MV3 disallows certain CSP modifications for extension_pages that were permitted in MV2. The script-src, object-src, and worker-src directives may only have the following values:

此外,MV3 不允许对 MV2 中允许的 extension_pages 进行某些 CSP script-srcobject-srcworker-src 指令可能只具有以下值:

  • self
  • none
  • Any localhost source, ( 任何本地主机源,(http://localhost, http://127.0.0.1, or any port on those domains) ,或这些域上的任何端口)

CSP modifications for sandbox have no such new restrictions.

CSP 修改沙盒没有这样的新限制。

🌹 browser_action & page_action 统一

具体查看: browserAction/说明文档 具体查看: pageAction/说明文档

MV2 中,有两个不同的 API 来实现 actions : browser_actionpage_action。他俩在最初引入时充当了不同的角色,但随着时间的推移,区分它们变得多余,所以在 MV3 中我们将它们统一为单一 action API:

// Manifest v2

// manifest.json
{
  "browser_action": { … },
  "page_action": { … }
}

// background.js
chrome.browserAction.onClicked.addListener(tab => { … });
chrome.pageAction.onClicked.addListener(tab => { … });
// Manifest v3

// manifest.json
{
  "action": { … }
}


// background.js
chrome.action.onClicked.addListener(tab => { … });

为了帮助迁移过程,Action API 可以从 Chrome 88 开始在 MV2 中使用。

🌹 web_accessible_resources 可访问资扩展源

web_accessible_resources 用于声明哪些扩展资源是公开的,哪些扩展来源是公开的。

应用场景: 使用 chrome.runtime.getURL 获取资源地址后,能使用该地址直接请求资源。

这一更改限制了对特定站点/扩展扩展资源的访问。原本是设置一个文件列表,而现在是设置一个对象列表,每个对象都可以映射到一组 resourcesURLsextension_ids:

// Manifest v2

"web_accessible_resources": [
  <files>
]
// Manifest v3

"web_accessible_resources": [{
  "resources": [<resources>],
  "matches": [<urls>],
  "extension_ids": [<keys>],
  // optional "use_dynamic_url": boolean
}]

use_dynamic_url 键还不可用。对此属性的支持将在以后的版本中提供。

以前,网络可访问资源列表适用于所有网站和扩展,这为指纹识别或无意识的资源访问创造了机会。更新后的 API 允许扩展更严格地控制其他站点或扩展可以访问哪些扩展资源。有关使用信息,请参阅 web accessible resources/可访问资源文档

🌹 Code execution 代码执行

MV3 imposes new restrictions that limit an extension's ability to execute unreviewed JavaScript through a combination of platform changes and policy limitations.

MV3增加了新的限制,通过平台更改和策略限制的组合,限制了扩展执行未经审查的 JavaScript 的能力。

Many extensions are unaffected by this change. However, if your MV2 extension executes remotely hosted scripts, injects code strings into pages, or evals strings at runtime, you'll need to update your code execution strategies when migrating to MV3.

许多扩展不受这一变化的影响。但是,如果 MV2扩展执行远程托管脚本、向页面注入代码字符串或在运行时进行 evals,那么在迁移到 MV3时需要更新代码执行策略。

With Manifest V3 the executeScript() method also moves to a different API.

使用 Manifest V3 executeScript() 方法也会移动到另一个 API。

If you use executeScript() anywhere in your code, you'll need to update that call to use the new API. The insertCSS() and removeCSS() methods similarly move from chrome.tabs to chrome.scripting.

如果在代码中的任何地方使用 executeScript() ,则需要更新该调用以使用新的 API。insertCSS()removeCSS() 方法类似地从 chrome.tabs 迁移到 chrome.scripting。

  chrome.tabs.query(
    { active: true, currentWindow: true },
    (tabs) => {
      // console.log(tabs);
      const tab0 = tabs[0];
      const tabUrl = tab0.url;
      if (tabUrl.includes('chrome://extensions/')) return;
      // 不 return 会报错: Unchecked runtime.lastError: Cannot access a chrome:// URL
      chrome.tabs.executeScript(tabs[0].id, {
        allFrames: false,
        code: contentFun.toString(),
      });
    }
  );
// background.js 后台脚本
  chrome.tabs.query(
    { active: true, currentWindow: true },
    function (tabs) {
      // console.log('获取到 tabs 信息:', tabs);
      const target = { tabId: tabs[0].id };

      // 插入 js 文件
      chrome.scripting.executeScript(
        {
          target,
          files: ['js/boss/background.js'],
        },
        (result) => {
          console.log(`bg.js 已经完成了编程式注入内容脚本。${JSON.stringify(result)}`);
        }
      );

      // 插入 css 代码
      const css = 'body { background-color = "red"; }';
      chrome.scripting.insertCSS({
        target,
        css: css,
      });
    }
  );

Remotely hosted code 远程托管代码

Remotely hosted code refers to any code that is not included in an extension's package as a loadable resource. For example, both of the following are considered remotely hosted code:

远程承载的代码引用扩展包中未包含的任何代码作为可加载资源。例如,以下两种代码都被认为是远程托管代码:

  • JavaScript files pulled from a remote server 从远程服务器获取的 JavaScript 文件
  • a code string passed into eval at runtime 在运行时传入 eval 的代码字符串

In MV3, all of your extension's logic must be bundled with the extension. You can no longer load and execute a remotely hosted file. A number of alternative approaches are available, depending on your use case and the reason for remote hosting. Two such approaches are:

在 MV3中,扩展的所有逻辑都必须与扩展绑定在一起。无法再加载和执行远程托管文件。根据您的用例和远程托管的原因,可以使用许多替代方法。其中两种方法是:

Configuration-driven features and logic—In this approach, your extension loads a remote configuration (for example a JSON file) at runtime and caches the configuration locally. The extension then uses this cached configuration to decide which features to enable.

配置驱动的特性和逻辑ー在这种方法中,扩展在运行时加载远程配置(例如 JSON 文件) ,并在本地缓存配置。然后,扩展使用这个缓存的配置来决定启用哪些特性。

Externalize logic with a remote service—Consider migrating application logic from the extension to a remote web service that your extension can call. (Essentially a form of message passing.) This provides you the ability to keep code private and change the code on demand while avoiding the extra overhead of resubmitting to the Chrome Web Store.

使用远程服务具体化逻辑ーー考虑将应用程序逻辑从扩展迁移到您的扩展可以调用的远程 web 服务。(本质上是消息传递的一种形式)这使您能够保持代码的私有性,并根据需要更改代码,同时避免了重新提交到 Chrome Web Store 的额外开销。

🌹 executeScript 执行脚本

executeScriptdetails 对象的 code 属性在 MV3 中不再可用。

不要执行一个字符串代码,你应该将你的代码移动到一个静态 JS 文件中,然后使用 executeScript 方法的 file 属性执行它:

// Manifest v2

// background.js
chrome.tabs.executeScript({
  code: 'alert("test!")'
});
// Manifest v3

// background.js
chrome.scripting.executeScript({
  file: 'content-script.js'
});

// content-script.js
alert("test!");

或者,如果执行的逻辑可以整齐地包装在一个函数调用中,你可以使用新的 function 属性:

// Manifest v2

// background.js
chrome.tabs.executeScript({
  code: 'alert("test!")'
});
// Manifest v3

// background.js
function showAlert() {
  alert("test!");
}

// let [tab] = await chrome.tabs.query({
//   active: true,
//   currentWindow: true,
// });
chrome.scripting.executeScript({
  // target: { tabId: tab.id },
  function: showAlert
});

🌹 background & service workers

MV2 中的 background page 被 MV3 中的 service workers 所替换: 这是影响大多数扩展的基础更改。

Service workers 是基于事件的,并且与事件页面一样,他们不会在调用之间持久存在。这种更改通常需要重新设计,需要考虑一些因素: 请参阅 从 Background Pages 迁移到 Service Workers 以获得更多详细信息。

为了帮助迁移过程, MV2 扩展可以使用 Chrome 87 中的 background service workers

// V2
  "background": {
    "scripts": ["background.js"],
  },
// V3
  "background": {
    "service_worker": "background.js"
  },

Modifying network requests 修改网络请求

There is a new declarativeNetRequest for network request modification, which provides an alternative for much of the webRequest AP's functionality.

有一个新的用于网络请求修改的 declarativeNetRequest,它为 webrequestap 的大部分功能提供了一个替代方案。

When can you use blocking webRequest? 什么时候可以使用阻塞式 webRequest?(#when-use-blocking-webrequest)

The blocking version of the webRequest API still exists in MV3 but its use is restricted to force-installed extensions only. See Chrome Enterprise policies: ExtensionSettings, ExtensionInstallForcelist.

webRequest API 的阻塞版本仍然存在于 MV3中,但它的使用仅限于强制安装的扩展。请参阅 Chrome 企业策略: ExtensionSettings,ExtensionInstallForcelist。

All other extensions must now use declarativeNetRequest for network request modification. This moves the actual modification of the network request into the Chrome browser: the extension no longer can read the actual network request, and in most cases needs no host permissions.

所有其他扩展现在必须使用 declarativeNetRequest 修改网络请求。这将网络请求的实际修改移动到 Chrome 浏览器中: 扩展不再能够读取实际的网络请求,并且在大多数情况下不需要主机权限。

Request redirects and header modifications do require the user to grant host permissions.

请求重定向和标头修改确实需要用户授予主机权限。

How do you use declarativeNetRequest? 如何使用 declarativeNetRequest?(#how-use-declarativenetrequest)

Instead of reading the request and programmatically altering it, your extension specifies a number of rules, which map a set of conditions to corresponding actions. See the declarativeNetRequest reference documentation for a more detailed description of rules.

您的扩展指定了一些规则,这些规则将一组条件映射到相应的操作,而不是读取请求并以编程方式修改它。有关规则的更详细描述,请参阅 declarativeNetRequest 参考文档。

This feature allows content blockers and other request-modifying extensions to implement their use cases without requiring host permissions, and without needing to read the actual requests.

这个特性允许内容拦截器和其他请求修改扩展实现它们的用例,而不需要主机权限,也不需要读取实际的请求。

In order to aid with the migration process, the declarativeNetRequest API is available for use in MV2 extensions as of Chrome 84.

为了帮助迁移过程,从 Chrome 84开始,declarativeNetRequest API 可用于 MV2扩展。

Conditional permissions and declarativeNetRequest 条件权限和 declarativeNetRequest(#declarativenetrequest-conditional-perms)

Most use cases for declarativeNetRequest don't require any host permissions at all. However, some do.

大多数 declarativeNetRequest 的用例根本不需要任何主机权限。

Request redirects and header modifications do require the user to grant host permissions.

请求重定向和标头修改确实需要用户授予主机权限。

When extensions require host permissions for these use cases, we recommend a "tiered" permissions strategy. This means implementing the extension's core functionality without using these permissions; putting the more advanced use cases behind an optional permission.

当扩展需要这些用例的主机权限时,我们建议使用“分层”权限策略。这意味着在不使用这些权限的情况下实现扩展的核心功能; 将更高级的用例放在可选权限之后。

This approach allows privacy-conscious users to withhold those permissions and still use much of the extension's functionality. This means that developers can implement many common use cases, such as content-blocking functionality, without requiring any host permissions.

这种方法允许注重隐私的用户拒绝这些权限,但仍然使用扩展的大部分功能。这意味着开发人员可以实现许多常见的用例,例如内容阻塞功能,而不需要任何主机权限。

Sunset for deprecated APIs 不推荐的 api 的日落

There are a number of APIs that have long been deprecated. Manifest V3 finally removes support for these deprecated APIs. These include:

有许多 api 早已被弃用。Manifest V3最终取消了对这些已弃用 api 的支持。其中包括:

  • chrome.extension.sendRequest() chrome.extension.sendRequest ()
  • chrome.extension.onRequest 1. chrome.extension.onRequest
  • chrome.extension.onRequestExternal 扩展. onrequestexternal
  • chrome.extension.lastError
  • chrome.extension.getURL() chrome.extension.getURL ()
  • chrome.extension.getExtensionTabs() chrome.extension.getExtensionTabs ()
  • chrome.tabs.Tab.selected
  • chrome.tabs.sendRequest()
  • chrome.tabs.getSelected()
  • chrome.tabs.getAllInWindow()
  • chrome.tabs.onSelectionChanged
  • chrome.tabs.onActiveChanged
  • chrome.tabs.onHighlightChanged

As well as the undocumented:

以及非法移民:

  • chrome.extension.sendMessage() chrome.extension.sendMessage ()
  • chrome.extension.connect() Chrome.extension.connect ()
  • chrome.extension.onConnect 1. chrome.extension.onConnect
  • chrome.extension.onMessage 1. chrome.extension.onMessage

If your extensions use any of these deprecated APIs, you'll need to make the appropriate changes when you migrate to MV3.

如果您的扩展使用了这些不推荐的 api 中的任何一个,那么在迁移到 MV3时需要进行适当的更改。

Last updated: Monday, November 9, 2020 • Improve article

最后更新: 星期一,2020年11月9日•改进文章