更新 Firefox 4 的扩展

用户界面更改

状态栏

Firefox 4 已移除状态栏，取而代之的是新的附加组件栏。有关详细信息，请参阅 附加组件栏。

工具栏

创建工具栏

如果您的附加组件使用覆盖（overlay）创建新工具栏，则该工具栏可能不会显示。当您的 <toolbox> 元素覆盖是 <window> 元素的子项而不是覆盖元素的直接子项时，就会发生这种情况。将工具箱移出窗口元素即可解决此问题。

Firefox 应用程序菜单

在 Windows 上，菜单栏现在默认隐藏。取而代之的是一个打开简化 Firefox 应用程序菜单的按钮。此菜单包含最常用的菜单功能，使应用程序更易于使用。仍然可以通过按 Alt 键访问菜单栏。

如果您的附加组件只能通过菜单栏访问，您也需要覆盖应用程序菜单。扩展菜单项没有特定位置，因此您应该查看菜单并为您的特定扩展选择合适的位置。

标签页

为了支持应用标签页（app tabs）和全景（Panoramas）以及使标签栏成为标准工具栏，对 <tabbrowser> 元素进行了一系列更改。其他可能破坏现有扩展的更改包括：

• TabClose、TabSelect 和 TabOpen 事件不再冒泡到 <tabbrowser> 元素（gBrowser）。这些事件的事件监听器应添加到 gBrowser.tabContainer，而不是直接添加到 gBrowser。
• 标签页上下文菜单不再是 <tabbrowser> 的匿名子项。因此，可以直接使用 XUL 覆盖对其进行覆盖。也可以通过 gBrowser.tabContextMenu 在 JavaScript 中更直接地访问它。有关更多详细信息，请参阅 此博客文章。

XPCOM 更改

对包含 XPCOM 组件的附加组件和应用程序进行了一些更改。有关详细信息，请参阅 Gecko 2 中的 XPCOM 更改。

附加组件管理器

经过大修的附加组件管理器现在作为标签页实现，而不是在单独的窗口中。从用户体验角度影响您浏览器的一些更改是，您的附加组件图标现在可以是 64x64 像素，而不是 32x32。虽然 32x32 像素的图标仍然可以使用，但显然，如果您的附加组件提供 64x64 像素的图标，看起来会更好。幸运的是，64x64 图标向后兼容且缩放效果好，因此您可以直接切换，而无需同时使用两种尺寸。

此外，附加组件管理器的后端也进行了重新设计。nsIExtensionManager 接口已消失，它使用的旧的基于 RDF 的存储也已消失。附加组件元数据现在存储在 SQLite 数据库中，附加组件管理器现在是一个名为 AddonManager 的 JavaScript 代码模块。

新 API 的一个关键区别是，请求附加组件元数据现在是异步的，而不是同步的；这同样适用于使用 FUEL 的附加组件，因此所有请求附加组件元数据的附加组件都需要更新。

线程

您现在不能在线程之间传递 JavaScript 对象。这使得线程管理器对附加组件开发人员来说几乎无用，而且目前没有太多替代方案。未来，ChromeWorker 可能会得到改进以填补这一空白。

网络重定向

处理网络重定向的 API 已更改为异步；在“net-channel-event-sinks”类别中注册的任何附加组件都需要更新以使用新的 asyncOnChannelRedirect API。

XPI 解包

Firefox 4 不再解压 XPI 文件进行安装。它只将 XPI 文件放置在用户配置文件中，然后直接从 XPI 读取 chrome 文件和其他文件。XPI 中的 jar 包仍然可以使用，但不再是必需的，这可以使您的开发或构建更轻松。这样做主要是为了在慢速操作系统上的性能考虑，并且允许更好的缓存失效，这对开发人员也有帮助。但是，并非所有类型的文件都可以从 XPI 中读取，因此如果您的扩展使用了其中一种文件，则需要在 install.rdf 中指定 <em:unpack>，以便 Firefox 仍然解压您的 XPI 并使用单个文件，否则您的扩展在尝试访问这些文件时将失败。

如果您的扩展只包含这些类型的文件，则无需进行任何更改

• install.rdf
• chrome.manifest
• chrome（包括 content、locale、skin）
• 默认首选项
• 用 JavaScript 编写的 XPCOM 组件

如果您的扩展包含以下任何内容，则需要将 <em:unpack> 添加到 install.rdf 中

• 二进制 XPCOM 组件
• 使用 ctypes 加载的共享库
• searchplugins/（应由 Firefox 自动加载）
• dictionaries/
• 窗口图标（可能已 修复）

如果您的扩展代码访问您已打包在 XPI 中的其他文件，您需要将 <em:unpack> 添加到 install.rdf 中，或者您可以通过对代码进行一些更改来支持打包安装。任何使用 getInstallLocation() 和 nsIFile 的代码都需要 em:unpack 或需要更改。您可以使用 Addon.getResourceURI() 方法，它将返回一个指向请求文件的 nsIURI。如果扩展已解包，则它将是一个 file:// URI。如果扩展已打包，则它将是一个 jar:// URI。您可以通过使用 nsIIOService 打开通道来打开这些 URI 的流，这样您就可以加载文件内容而无需解包。

已移除子 HWND

这只会影响极少数开发人员。在以前版本的 Firefox 中，Windows 会为内部使用创建子 HWND。作为改进图形性能工作的一部分，这些已不再创建。

不幸的是，一些扩展访问了这些 HWND 并直接操作它们；这些扩展在 Firefox 4 中将不再起作用。我们已采取了一些变通方法来帮助某些指向设备驱动程序和辅助技术软件（例如屏幕阅读器）。但是，我们决定不再添加更多变通方法来支持扩展，而这些扩展从一开始就不应该这样做。

如果您维护一个使用依赖于已不存在的 HWND 的本机组件的扩展，您需要更新您的扩展。有两种方法可以做到这一点。

第一种也是更好的一种解决方案是停止访问 HWND，而是使用 Web 功能或 XUL 来实现您的扩展。Firefox 4 中有许多新功能，可以实现许多以前需要本机代码才能完成的任务，因此您可能不再需要这样做。

如果您发现此方法不起作用，并且仍需要直接访问 HWND，您可能会发现唯一的解决方案是编写一个 NPAPI 插件来完成工作。这可能需要大量工作，但应该有效。当然，如果您使用的特定 HWND 不再存在，这可能也无济于事。

开发和测试技巧

缓存

由于 Firefox 现在更积极地缓存代码和其他资源，因此您需要在启动 Firefox 4 时清除缓存。否则，您可能会测试过时的附加组件部分。要做到这一点，请使用 -purgecaches 命令行选项运行 Firefox。

配置文件管理器

旧的配置文件管理器工具将在 Firefox 4 中被移除，尽管目前尚未移除。此工具长期以来未更新，并且缺少功能。此外，它的存在正在减慢应用程序启动速度。

配置文件管理器的替代品 可用。（另请参阅 Firefox bug 539524）。此新工具独立于浏览器本身，并且比旧的配置文件管理器更健壮。

全局安装扩展

已移除 -install-global-extension 和 -install-global-theme 命令行选项。全局安装的处理一直很复杂，并且正在就未来如何解决这个问题进行讨论。在此期间，请参阅 安装扩展 以获取有关自动安装附加组件的信息。

另见

• 使您的附加组件与 Firefox 4 兼容（博客文章）