User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0 (Beta/Release) Build ID: 20130307023931 Steps to reproduce: Upgrade from Firefox 19 to any version from 20 upwards. Actual results: Local user profile Addon databases get erased during the upgrade. Addons installed to the program install folder do not get registered any more in any user profile. Every user is forced to register and upgrade addons on his own. There is no more possibility to provide users with predefined sets of addons without grabbing into the user profiles by the admin. What means: Breaking of rules of responsible behavior from the viewpoint of an admin. Multiplying workload on the admin. Multiplying dataload on the network. Extremely blatant in environments, where an admin has to provide hundreds of workstations with upgrades. Expected results: As it was up to version 19, Addons installed under the program install folder should be implicitly loaded under each and every user profile. So to provide a bunch of addons by the admin at a centralized place, doing a one time installation or upgrade, taking effect for each and every user profile from that moment on. Instead of having to poke around a dozent of times at least each and every month at each and every upgrade of firefox and additionally at each and every update of each and every addon on its own. Gelle?! That's simply stupid. Up to version 19, it was possible to do provide installs of and upgrades to addons at a centralized place, with very little workload and even very little load to LAN networks in case those addons needed upgrades. From version 20 on that became forced to decentralize. The latter should NOT happen!
I don't see anything about that in Firefox 20: 1) https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/20 2) https://blog.mozilla.org/addons/2013/03/20/compatibility-for-firefox-20/ In addition, it would be better to use the lastest stable version which is Firefox 21. Don't forget Firefox ESR version is designed for corporates/schools/large organizations etc... http://www.mozilla.org/en-US/firefox/organizations/
Firefox ESR (effectively downgrade to version 17, but including critical bugfixes) would be an option. And of course for testing it would be better to use the most current nightly build, not just the latest release. But for the localization of the causing code change, it would be best to compare the latest 19 with the first 20 version. Because that's the point where this behavior started. In the release notes, there is neither anything in the developer nor anything in the user release notes for either the 20 or the 21 version, which may give a hint to this behavior.
About add-on install tips, you may read Mike Kaply's blog, it's very useful to find some up-to-date details about config files (prefs, add-ons etc): http://mike.kaply.com/
OK, testing http://mike.kaply.com/2013/05/13/more-major-changes-coming-in-firefox-21/ (Did i get something wrong with the version number??)
OK, that solved it. And it obviously was not the version transition 19->20, but 20->21. Sorry: Lazy logging from my side.
In the release notes, even in the complete list at bugzilla, there is not a single hint for this change. I have searched with keywords "browser" "extension" "folder" and glimpsed through the matching entries. But found no match for this specific change. Is there some special point anywhere in the mozilla hierarchy where you can find hints to those "hidden changes"?
(In reply to White-Gandalf from comment #7) > In the release notes, even in the complete list at bugzilla, there is not a > single hint for this change. I have searched with keywords > > "browser" > "extension" > "folder" It's bug 842334.
Ah ja, Firefox 24... 2 month ahead... OK, one less surprise when the time comes by... :D
Just for correctness: Let me change version to branch 21...