使用chrome.tabs与browser.tabs进行浏览器兼容

Question

我已将Chrome扩展程序移植到Firefox。

根据MDN，有一个browser.tabs API应该由ch​​rome支持。

但browser不是Chrome稳定版中的对象。 同时chrome.tabs在Firefox中运行良好。

在阅读MDN文档时，用browser替换chrome是否安全？ 文档写browser的原因是什么？是否有计划的变化？

Answer 1

注意：在过去几天中，许多MDN JavaScript API页面已从使用chrome.*更改为使用browser.*并描述了由browser.*界面。这些更改使得页面没有提及使用API​​ chrome.*。这些更改是由项目中的同一个人进行的，我与之讨论了从browser.*到chrome.*的更改。我还不知道发生了什么事。我已经给他发了电子邮件，询问这些变化的原因。截至2016-11-02的编辑，现在要期待他的反应还为时过早。

我没有参与API的工作。但是，我已经针对WebExtensions chrome.*与browser.*进行了一些具体的API文档更改（截至2016-09，所有页面都已更改为显示chrome.*） -22）。我参与其中是因为我发现大多数WebExtensions API页面显示browser.*令人困惑。我想知道chrome.*和browser.*之间的区别。一旦我发现了，我想让其他人不那么困惑。

WebExtensions browser.* API returns a promise：

当您调用API时，browser.*对象会实现the API that returns a promise if you omit providing a callback function的版本。目的是chrome.*和browser.*的实际功能相同。如果您向browser.* API提供回调函数，则其功能与chrome.* API完全相同。

  

在阅读MDN文档时，将browser替换为chrome是否安全？

是的，除非文档专门讨论承诺。两者之间的唯一区别是，如果在调用API时未提供回调函数，browser.*方法将返回一个promise。

  

文档写browser的原因是什么？

我不确定为什么这些文档最初是以browser.*如此突出的方式编写的。我假设这是在生成页面时进行的配置选择，或者在实现WebExtensions API的早期某些时候chrome.*和browser.*之间的差异细节发生了变化。

  

没有回调的chrome.*无法返回承诺，是否存在技术原因？

到目前为止，我提出的唯一原因是使用chrome.*返回promises将导致在API中执行参数检查时无法检查是否存在强制回调函数。使用browser.*命名空间，API可以假定调用者正在使用返回的promise。因此，使用browser.*可以返回promise，而不是在API调用中未提供强制回调函数时生成错误。然而，这是我的推测。

更改文档：

我同意API文档主要在“语法”部分中显示browser.*，并且每个API页面中的其他位置都令人困惑（例如在示例中）。我一直在讨论在过去3周内主要负责WebExtensions文档的人员在整个API文档中更改此内容。他同意应该改变它。

有计划进行改变。文档将至少在两个阶段发生变化。第一个是浏览所有WebExtensions API页面并将语法部分更改为chrome.*。语法部分末尾的注释表示＆＃34; API在version that returns a promise中也可用作browser.*。＆＃34;此外，整个页面中browser.*的所有使用都将更改为chrome.*，除了那些专门显示API用作返回承诺的部分。

目前的预期是该页面看起来很像alarms.clear()。我更改了该页面以显示我建议更改的内容，包括WebExtensions文档负责人的建议。 alarms.clear()语法部分目前看起来像：

最初（3周前，2016-08-25），我已将API页面从alarms.clear()更改为browserAction.enable()，主要更改了将内容从browser.*移至chrome.* chrome.*当我对MDN进行更改的访问权限因其自动垃圾邮件过滤而被禁用时。这导致讨论了更改将采用的格式。我暂停进行更改，希望一旦选择了Syntax框的中间格式，就可以一次完成初始更改。由于现实生活，双方的讨论时间比我预期的要长。

看起来关于将使用的确切格式的讨论将扩展到包括dev-mdc mailing list，因为＆＃34;正确＆＃34;语法框格式未在Mozilla documentation for how to write an API method page中清除。

但是，我相信我可以继续更改显示browser.*而不是browser.*。这样做可能会导致必须再次编辑页面以获取最终决定为官方格式的格式。在最终确定语法块格式之前进行chrome.*到chrome.*更改可能会导致更多的整体工作，但会在讨论格式更改的最终版本时减少混淆。虽然我必须逐页进行这些更改（有一个用于进行批量更改的API，但我没有访问权限），但我已经实现了一个脚本，可以进行大部分所需的更改。因此，这些最初的不应该花太长时间。

<强>更新
我已将所有WebExtensions JavaScript API页面更改为显示browser.*而非browser.*。您可能需要在每个页面上按 Ctrl - F5 查看更改。

进一步更改，更明确地提供有关chrome.*的文档：
在对语法块格式进行完全更改之后，需要稍后进行其他更改，以便在每个API页面的基础上提供更多示例，说明使用browser.*和{之间的差异{1}}。这几乎肯定是一个长期项目。