如何让Firefox自动更新与应用程序捆绑在一起的扩展

本文介绍了如何让Firefox自动更新与应用程序捆绑在一起的扩展的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 限时删除！！ 我们公司的FF扩展包含了我们应用程序的安装包（即与应用程序捆绑在一起，而不是Firefox版本）。在安装过程中，扩展程序目前通过Windows注册表（在 HKCU / Software / Mozilla / Firefox / Extensions 中的新键）添加到Firefox。 我的任务是为这个扩展启用自动更新。为此，我把 updateUrl 放入 package.json ，创建了 update.rdf 以及更新版本的延期。因此，Firefox会找到更新的扩展名，但无法更新。 Firefox日志： 1464888839764 addons.update-checker DEBUG请求https：//path/update.rdf 1464888840017 addons .update-checker DEBUG找到< My Addon Name>的更新条目版本1.2.3 1464888840022 addons.xpi DEBUG为< My Addon Name>找到一个现有的AddonInstall。 1464888840024 addons.manager DEBUG找到附加组件的更新<我的插件名称> 1464888840026 addons.manager DEBUG onUpdateFinished for< My Addon Name> 相比之下，如果MyAddonName.xpi手动安装（即不使用Windows注册表）自动更新正常工作。 问题是： 如果Firefox故意跳过自动更新注册表安装的扩展，我们的捆绑扩展使用普通的Firefox插件自动更新启用安装？ 到目前为止我已经找到了这个：在 firefox-44.0\toolkit\mozapps\\ \\ extensions \internal\XPIProvider.jsm if（！this._installLocation.locked&& ！this.pendingUninstall）{ //通过文件链接安装的加载项无法升级 if（！this._installLocation.isLinkedAddon（this.id））{ permissions | = AddonManager.PERM_CAN_UPGRADE; } 权限| = AddonManager.PERM_CAN_UNINSTALL; $ b $ p $ b 这是故意禁止从本地安装的附件更新的行为我们正在一些限制条件下工作： 安装必须工作对于具有用户权限的Windows帐户。换句话说，％程序文件％不可写，也不需要授权给普通用户的权限（即安装不能认为该帐户具有高级用户或管理员的扩展功能）。 捆绑的扩展应安装到所有当前已有的Firefox配置文件中，以供安装该应用程序的用户使用。 系统的其他用户不应受到影响。 b $ b 捆绑的扩展应该由Firefox通过Firefox用来自动更新插件的正常流程自动更新。 Firefox扩展的自动更新不能搭载在我们的应用程序中存在的任何自动更新功能。这样的功能可能存在，也可能不存在，但必须使用正常的Firefox附加自动更新功能。 我们需要一种方法来禁用Firefox我们的应用程序的所有配置文件中的扩展。 扩展名，例如你的，通过Firefox发行版外部的安装程序应用于多个配置文件的扩展名将由Firefox外部的进程更新。这个结果是没有解决方案，干净和容易。 鉴于你正在工作的限制，我会完成你想要的方式是有一个加载程序扩展是通过将其安装在目录中： ％appdata％\Mozilla\Extensions\ {ec8030f7-c20a-464f-9b0e-13a3a9e97384} 或者，您可以像当前那样使用Windows注册表。但是，使用Windows注册表似乎将视为已过时。使用这两种方法都会导致扩展程序被安装在用户和所有新创建的配置文件的所有当前配置文件中。 在某些情况下，附件将被安装并而不询问用户（重新启动的插件，新创建的配置文件，在目录中），在其他情况下，将要求用户安装插件的权限（XUL覆盖插件，在目录中，新创建和现有配置文件）。在另一些情况下，加载项将被作为禁用（Windows注册表，无重启加载项）加载到附加列表中。我没有足够的测试来确定一个完整的行为表。我不知道你想要的行为是什么。您需要检查以确认所使用的方法会导致加载器扩展应用于Firefox配置文件。 加载器扩展的功能是： / b> 在Firefox启动/扩展程序安装后，检查您希望/需要的所有扩展程序是否已安装（未必启用）。如果有任何不存在的地方，那么将它们安装到扩展的常规方法的配置文件中（这将导致这些扩展被自动更新，而不是加载器扩展）。 也想要它，通过选项/首选项/ 简单首选项，为用户提供验证所需扩展的安装并启用/禁用它们的方法。 它作为已安装/已启用的存在扩展名被用作主要扩展名的标志，可以被接受运行。如果加载程序未安装/启用，您的其他扩展禁用/卸载本身。这包括如何从外部应用程序中禁用主扩展。 $ b 您的加载程序加载项安装的扩展名为/是您目前与您的应用程序捆绑在一起的那个。 加载器扩展可以通过直接文件操作（不推荐）或使用附加组件管理器。附加组件管理器具有从 file 或者 使用Windows注册表安装捆绑扩展是认为已过时。如果您使用目前记录的捆绑扩展方法 ，则在创建配置文件时，扩展文件将被复制到每个配置文件的 extensions 目录中，或者使用该配置文件首次运行该版本的Firefox。从那时开始，扩展名将自动更新。 放置捆绑扩展的正确目录（如 .xpi 文件，未解压缩） in： $ b $ em安装目录/ distribution / extensions 如果在配置文件之后向目录添加扩展名已经创建并运行了该版本的Firefox，那么扩展程序将不会被复制到该配置文件的 extensions 目录。 用户将完全控制其配置文件目录中的扩展副本，包括将其从配置文件中删除的功能。其他为多个用户/配置文件安装扩展程序的方法将只允许它们禁用它，而不会自动更新。 当前行为： > Firefox所做的事情看起来正是它应该做的事情，并且与文档一样。通过将引用（ .xpi 文件，目录结构，文件链接，文件链接等）安装到外部代理（用户或安装脚本，手动放置文件或使用Firefox构建打包）等等）在一个位置，多个Firefox配置文件可能会执行扩展名，而不会将其复制到每个配置文件中（例如，使用Windows注册表），那么Firefox会假定外部代理机构将负责更新附加组件。在这种情况下，Firefox不会更新附加组件。 我猜测这是因为任何自动更新都是从特定的配置文件多用户系统上的特定用户）。对于任何特定的配置文件/用户来说，自动更新其他配置文件/用户正在使用的可能具有附加文件被锁定或正在使用的扩展名是不合适的。尽管Firefox通过在配置文件中自动更新Firefox本身来解决这个问题，但是我的假设是，对于扩展而言，这被认为是不恰当的。 必须： 将捆绑的扩展放在 [Firefox安装位置] / distribution / extensions目录下。这是用Firefox构建捆绑扩展的常用方法。 把扩展放到别的地方（ multiple 的可能性）。您需要为您的Firefox捆绑安装提供额外的方法来检查与其捆绑在一起的扩展的更新。 通过最简单的方法就是将你的捆绑扩展包含在 [Firefox安装目录] / distribution / extensions目录中。 Our's company FF extension ships with the installation package of our application (i.e it's bundled with the application, not a Firefox build). During installation, the extension is currently added to Firefox by means of the Windows registry (a new key in the HKCU/Software/Mozilla/Firefox/Extensions).My task is to enable auto-update for this extensions. To do that I've put updateUrl into package.json, created update.rdf along with the newer version of extension. As a result, Firefox finds an updated extension but fails to update it. Firefox logs:1464888839764 addons.update-checker DEBUG Requesting https://path/update.rdf1464888840017 addons.update-checker DEBUG Found an update entry for <My Addon Name> version 1.2.31464888840022 addons.xpi DEBUG Found an existing AddonInstall for <My Addon Name>1464888840024 addons.manager DEBUG Found update for add-on <My Addon Name>1464888840026 addons.manager DEBUG onUpdateFinished for <My Addon Name>In contrast, if MyAddonName.xpi is installed manually (i.e. without the use of the Windows registry), auto-update works fine.The questions is:If Firefox deliberately skips auto-updating of registry-installed extensions, how can our bundled extension be installed with normal Firefox add-on auto-updating enabled?So far I've found this: in firefox-44.0\toolkit\mozapps\extensions\internal\XPIProvider.jsmif (!this._installLocation.locked && !this.pendingUninstall) { // Add-ons that are installed by a file link cannot be upgraded if (!this._installLocation.isLinkedAddon(this.id)) { permissions |= AddonManager.PERM_CAN_UPGRADE; } permissions |= AddonManager.PERM_CAN_UNINSTALL;}That is deliberate behavior of disabling update for add-ons that were installed from local folders.We are working under some constraints:The installation must work for a Windows account with User permissions. In other words, %program files% is not writable, nor anything that requires permissions not granted to normal Users (i.e installation can not assume that the account has the expanded capabilities of a Power User, or Administrator).The bundled extension should be installed into all currently existing Firefox profiles for the user installing the application.Other users of the system should not be affected.The bundled extension should be auto-updated by Firefox through the normal process Firefox uses to automatically update add-ons.The auto-updating of the Firefox extension can not piggyback on any auto-updating capability that exists in our application. Such capability may, or may not, exist, but the normal Firefox add-on auto-updating capability must be used for the extension.We need a way to be able to disable the Firefox extension in all profiles from our application. 解决方案 Firefox is specifically designed with the assumption that any extension, such as yours, which is applied to multiple profiles by an install program external to the Firefox distribution will be updated by a process external to Firefox. This results in no solution which is clean and easy.Given the constraints you are working under, the way I would accomplish what you desire is to have a loader extension which is installed either via placing it in the directory:%appdata%\Mozilla\Extensions\{ec8030f7-c20a-464f-9b0e-13a3a9e97384}Alternately, you can use the Windows registry as you currently do. However, using the Windows registry appears to be considered obsolete. Using either method will result in the extension being installed in all currently existent profiles for the user and all newly created profiles.In some situations the add-on will be installed and active without asking the user (restartless add-on, newly created profile, in directory), in other instances the user will be asked for permission to install the add-on (XUL overlay add-on, in directory, both newly created and existing profile). In yet other instances, the add-on will be entered in the add-on list as disabled (Windows registry, restartless add-on). I have not tested enough to determine a complete chart of the what the behavior is. I do not know what you desire the behavior to be. You will need to check to verify that the method used results in the loader extension being applied to Firefox profiles as you desire.The function of the loader extension is to:Upon Firefox startup/extension install to check that all extensions you desire/need exist as installed (not necessarily enabled). If any don't exist, then install them in the profile in the normal method for extensions (this will result in those extensions being automatically updated, but not the loader extension).You may also want it, through the options/preferences/simple-prefs, to provide a way for the user to verify the installation of the needed extension(s) and enable/disable them.Its existence as an installed/enabled extension is used as a flag to your main extension(s) that it acceptable to run. If the loader is not installed/enabled, your other extension disables/uninstalls itself. This covers how you can disable your main extension from your external application.The extension(s) your loader add-on installs is/are the one(s) that you are currently bundling with your application.The loader extension can install extensions either through direct file manipulation (not recommended), or using the Add-on Manager. The Add-on Manager has methods for installing extensions from either a file or URL.Old understanding of question (extension bundled with Firefox build, or at least the ability to write to the Firefox install directory):Using the Windows registry to install bundled extensions is considered obsolete. If you use the currently documented method of bundling extensions, the extension file will be copied into the extensions directory of each profile upon profile creation, or the first run of that version of Firefox using that profile. From that time on, the extension will be automatically updated.The correct directory to place bundled extensions (as .xpi files, not unpacked) in:[Firefox install directory]/distribution/extensionsIf you add extensions to that directory after a profile has been created and has run that version of Firefox, then the extension will not be copied to the extensions directory for that profile.The user will have full control over the copy of the extension that is within their profile directory, including the ability to remove it from the profile. Other methods of installing the extension for multiple users/profiles will only permit them to disable it while not automatically updating.Current behavior:What Firefox does appears to be exactly what it should do and is as documented. If the extension is installed by an external agency (user, or install script, manually placing the file, or packaged with the Firefox build) by placing the reference (.xpi file, directory structure, file link, etc.) in a location from which multiple Firefox profiles might execute the extension without copying it into each profile (e.g. using the Windows registry), then it is assumed by Firefox that the external agency will take care of updating the add-on. In those cases, Firefox will not update the add-on.I surmise that the reason for this is that any automatic updating occurs from within a specific profile (which is from a particular user on multi-user systems). It would be inappropriate for any specific profile/user to auto-update extensions that are in use by other profiles/users which might have the add-on file(s) locked or in-use. While Firefox breaks this by having the automatic updates of Firefox itself occur from within profiles, my assumption is that it was considered inappropriate for this to occur for extensions.The options you have are to:Place the bundled extensions in the [Firefox install location]/distribution/extensions directory. This is the normal method of bundling extensions with a Firefox build.Put the extensions somewhere else (multiple possibilities). You will need to have an additional method for your Firefox bundled install to check for updates to the extensions which are bundled with it.By far the easiest is to include your bundled extensions in the [Firefox install directory]/distribution/extensions directory. 这篇关于如何让Firefox自动更新与应用程序捆绑在一起的扩展的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 1403页，肝出来的..