canmove, Confirmed users
1,570
edits
Extension Manager:Install Locations: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
=Overview= | =Overview= | ||
The extension manager uses a number of install locations where extensions will be loaded from. Currently there is a very simple structure in place | The extension manager uses a number of install locations where extensions will be loaded from. Currently there is a very simple structure in place. Any add-ons installed by the user go into the profile install location, any other install locations are simply scanned for new items during startup. Any new items detected during startup are installed and activated with no user intervention (except in the case of xpi files dropped in). The install locations have priorities. If the same add-on exists in two different install locations then the one in the higher priority install location is used. The general set of install locations, ranging from low to high priority are: | ||
# Application installation directory | # Application installation directory | ||
| Line 14: | Line 14: | ||
* hidden tells the application to hide the add-on from the user | * hidden tells the application to hide the add-on from the user | ||
= | =Tweaking install locations= | ||
This proposal is to change the priority of some of the install locations and more explicitly define their purpose as well as to remove the use of the behaviour flags. The following install locations will exist (mostly the same locations as above, but re-ordered and explained). At the moment the computer-wide, user-wide and profile locations still follow a priority system for deciding which add-on to use. An alternative would be to use the newest compatible add-on from them. | This proposal is to change the priority of some of the install locations and more explicitly define their purpose as well as to remove the use of the behaviour flags. The following install locations will exist (mostly the same locations as above, but re-ordered and explained). At the moment the computer-wide, user-wide and profile locations still follow a priority system for deciding which add-on to use. An alternative would be to use the newest compatible add-on from them. | ||
| Line 33: | Line 33: | ||
This is an additional location, however it is not really an install location. It allows distributions to ship add-ons that the user then has complete control over. When a new version of the application is started, any add-ons here that have not been installed previously will be copied to the profile directory where the user may update or uninstall the add-on as they wish. | This is an additional location, however it is not really an install location. It allows distributions to ship add-ons that the user then has complete control over. When a new version of the application is started, any add-ons here that have not been installed previously will be copied to the profile directory where the user may update or uninstall the add-on as they wish. | ||
=Replacing flags= | |||
The flags are mostly replaced by the behaviours of the install locations. <code>locked</code> and <code>appManaged</code> simply apply to all add-ons in the application directory. The exception is <code>hidden</code> which no longer exists for regular add-ons. If system administrators need to install an add-on that the user cannot see then they can do so by including it as a regular distribution bundle. These will not show up in the extension manager. The only downside is that certain add-ons may not work there if they use certain APIs like the nsIInstallLocation APIs to find their files. | |||