User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Firstly, user data (user search plugins) is stored in the program folder, with no obvious way to have it stored anywhere else. Secondly, that user data is obliterated whenever a new version of Firefox is installed. Reproducible: Always Steps to Reproduce: 1. Install Firefox to same location as a previous installation. Actual Results: User loses data - it was willfully destroyed by the Firefox installer. Expected Results: All the usual symptoms associated with loss of data - tears, anguish, and so on. Also RSI caused by hundreds of clicks re-ordering plugins (more user data; the plugin order). note: personally, I have a backup from a few weeks ago, and a desktop macro that enbles me to do ten/twenty mouse clicks with a single hotkey, otherwise I'd.. a) be in tears at all the lost work creating all these lovely search plugins, and.. b) be looking to sue someone for the RSI caused by putting them all back into the correct order! I also have a windows hack that enables me to resize the infuriatingly small searchplugin dialog so that I can see what I'm doing. But God help new users! The software should (in order of preference).. a) Store user data in the user data folder (aka Firefox profile). I'm amazed no one has noticed this incredible faux-pas. b) NEVER delete non-factory plugins, no matter where they are. c) Offer to update new versions of existing search plugins during install (whilst leaving others alone, of course). d) (at the very least) warn user of impending data destruction during install process, and offer some options.

(In reply to comment #0) > a) Store user data in the user data folder (aka Firefox profile). We already do this. Plugins installed by the user are installed in the profile, since Firefox 1.5 (see bug 123315). What made you think otherwise?

Hmm.. because that's where mine are. I'm using Firefox 2, and they live in the program folder, have done since Firefox 0.x. If they "officially moved", my plugins certainly didn't "actually move" (and I always use the installers); the searcjplugins are still there! And still operate from there; changes applied there show in the search menu. Firefox still deletes them every install, and never thinks to move them to the user folder, or tell me that there's something wrong. But clearly there is. Why does the folder still exist? Why didn't Firefox move it, or tell me to? Why does it keep using it, and loading search plugins *from* it. Ang why does it still delete its contents and install a fresh set of factory plugins in there with the latest installer? (the deleting user data part of all this) "Not used"? Hardly!

Ah, yeah, we don't migrate existing plugins. Put your plugins in your profile instead of the appdir and you'll never have them deleted again.

Thanks, but I wasn't actually looking for technical support, I'm here to report the bugs. Please refer to my previous questions, which remain unresolved.

(In reply to comment #2) > Why does the folder still exist? > Why does it keep using it, and loading search plugins *from* it. Because we ship some search plugins with the app by default. > Why didn't Firefox move it, or tell me to? Because writing the code to move user-added search plugins, but not app-shipped plugins to the profile wasn't trivial, and deemed unnecessary based on the number of people likely to have custom plugins before this patch landed, and the relative ease of reinstalling them even if they were lost. See comments in bug 123315. > Ang why does it still delete its contents and install a fresh set of factory > plugins in there with the latest installer? (the deleting user data part of all > this) Because the only plugins that are supposed to be there are the app-shipped ones, which are included when you re-install. See bug 123315 comment 99. User data isn't supposed to be in that folder. I'm sorry that you lost plugins and have had to frequently restore them, but there's nothing we can change in Firefox now that will remedy that, so I'm going to resolve this INVALID. Now that you know about the profile search plugins directory you shouldn't have this problem anymore.

Like I said, I keep backups, so it's not a problem for me. And now I know that I can store them in my profile, it's anon-issue.. FOR ME. I'm not familiar with the mozilla platform, but surely code to move files, or post dialogs is *very* trivial. And regardless, even if were highly complex and involved, user data is at stake - Firefox DID use that folder for plugins, and users could add/edit them; ergo; that is user data; you can't explain away that fact. My point is simple; at no point did Firefox notify me, in any way, that there was a new location for the search plugins. Nor did Firefix respect (a simple backup would have been fine) what was obviously NON-APP data; simply obliterated it (error: programming 101, sir!). Or are loyal users (those using Firefox since pre 1.5) all expected to come here, one by one, and post bugs about it, wasting their time and yours in the process? I *did* search for this at bugzilla before posting. Perhaps someone should look at that. Or maybe add a FAQ item somewhere... SOMETHING. ANYTHING!

(In reply to comment #6) > My point is simple; at no point did Firefox notify me, in any way, that there > was a new location for the search plugins. Nor did Firefix respect (a simple > backup would have been fine) what was obviously NON-APP data; simply > obliterated it (error: programming 101, sir!). OK, point taken. What are you suggesting we do about it now? The Firefox 1.5 series has been EOLed. Are you suggesting that we should implement a special dialog for users users of Firefox 1.0 that have custom search plugins and are just now upgrading to Firefox 3? If it wasn't common enough to do back when we fixed this in 1.5 it's certainly not something we're going to do now.

Something as simple as this (pseudo code) would be fine.. for ($foo in "searchplugins/*") mv $foo %profile%/searchplugins The installer then does its usual thing. This way, long-time users of Firefox (I mailed a mate of mine who I know has a load of searchplugins, and he too didn't realise they had moved - and has been updating the main folder - I suspect we are not alone) will see that *miraculously* their plugins are still working after install. When they notice that their searchplugins folder is empty, or better yet, _no_longer_exists_, they will most likely look in the profile folder. Where else? Even better; Firfox could also post a wee dialog, to inform the user what has happened.. msgBox("Your search plugins have been moved to your profile folder. You can edit them there.") If it's really so much code to do this, then fair enough, I understand, and will strike "check out moz platform" from my 2do list. In all the programming languages I use regularly (a few), it's one or two lines, maybe three. Personally, if I thought one of my applications had the potential to destroy user data, especially if it was my fault that data was in the wrong place to begin with, I'd fix it, even if it meant staying up all night. But maybe that's just me. Anyways, thanks for at least considering all this. And, of course, for letting me know about the new searchplugin location! A real info-gem! Ta! ;o)

Alerting users on startup would be disruptive to the upgrade process and wouldn't be relevant to the majority of users. It would also be annoying if you did it repeatedly, and reliably detecting whether it's the first time a user's upgraded to a specific version isn't trivial. Moving all search plugins indiscriminately would mean that the majority of users would have multiple similarly-named search plugins (again, see bug 123315 comment 99), and we'd potentially lose the benefit of being able to update app-shipped engines in future releases.

Version is irrelevant. The only question is "are there user plugins there, or not?"; and if there are, the dialog would appear, one time only. After the plugins are moved, there is no further need for a notification. As for moving the plugins, simply; only move plugins which are NOT the app-shipped ones. I presumed (always a mistake) that that went without saying. if (non-app-shipped plugs exist) { move thos plugins post a dialog }

(In reply to comment #10) > As for moving the plugins, simply; only move plugins which are NOT the > app-shipped ones. How do you detect that they're not app shipped? Embed a manifest of all the names of plugins that have ever been shipped with any of the various localized builds of the app? That's entirely impractical. It would also result in false positives and would remove our ability to modify/upgrade engines that were once shipped by default. I think you should be careful about assuming that things are simple without really knowing how they work, or what kind of logic is involved. What you're proposing is not simple. Even if it were simple, there'd be no reason to do it at this stage anyways, we're nearly 2 major versions away from a build that would have been affected by this problem.

The search plugin list isn't some monster manifest, it's a handful of plugins; and as far as I know, they don't ever get *removed*, only added and updated. As for localization; simply use whatever logic the installer *already* uses to decide which localization belongs; move everything else. Whatever happens, it will happen only once - AND AT LEAST NO USER DATA WILL HAVE BEEN DELETED. I REPEAT: NO USER DATA WILL HAVE BEEN DELETED. THIS IS THE MAIN ISSUE. Aplogies for shouting, but I feel like you aren't hearing this bit. And "this stage"? What?!? It is not some "past version" of Firefox that is affected, it is human USERS that are affected, and with EVERY new version of Firefox. By the way, from reading bugzilla, I see the change was at v1.5; and according to this page... http://en.www.mozilla.com/en/firefox/ We (the users) are currently at v2.0. That equals *half* a major version, at least on my calculator. On the bright side, you did at least admit that it is a problem. The question is, how to solve it? I may not know the moz development process, but I think I recognize when someone is adding complexity for the sake of argument. Why not instead consider, "how could this be done, and simply?"

(In reply to comment #12) > The search plugin list isn't some monster manifest, it's a handful of plugins Wrong. We've shipped multiple plugins for every one of the locales we ship (at least 29 for Firefox 1.0), and they all had different filenames back then. They weren't particularly unique filenames, either - google-fr.src was used by both the shipped engine and the engine available on MyCroft, for example. > And "this stage"? What?!? It is not some "past version" of Firefox that is > affected, it is human USERS that are affected, and with EVERY new version of > Firefox. Wrong. It would have affected users once, when they upgraded from 1.0 to 1.5, and never again. It's happened to you on each upgrade because you kept copying your plugin files there. > On the bright side, you did at least admit that it is a problem. The question > is, how to solve it? I may not know the moz development process, but I think I > recognize when someone is adding complexity for the sake of argument. Why not > instead consider, "how could this be done, and simply?" That was considered when the original fix was landed. I've explained more than once why the decision was made to do what we did. You don't seem to accept my arguments. I'm not going to spend more of my time trying to convince you.

I would have accepted "we can't be bothered" as your first answer. Thanks.