Closed Bug 232638 Opened 21 years ago Closed 19 years ago

move searchplugins directory to profile

Categories

(Firefox :: Search, defect)

Product:
Firefox
Component:
Search
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 123315
Milestone:
Firefox1.0

People

(Reporter: bugzilla, Assigned: p_ch)

References

Details

(Whiteboard: [asaP1])

Attachments

(1 file)

Patch v1.0
10.74 KB, patch
Details | Diff | Splinter Review
User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040129 Firebird/0.8.0+ When uninstalling Firebird via the Control Panel, the uninstallation leaves the searchplugins directory (among other things) behind. However after reinstalling, the browser cannot see/use any search engines that the user had installed unless you go and reinstall those engines. Reproducible: Always Steps to Reproduce: 1. Uninstall Firebird from the Control Panel, Add/Remove Programs. Choose not to delete the entire directory when prompted. 2. Reinstall Firebird. 3. Start Firebird and check the search box dropdown menu. Actual Results: All installed search engines but the default (Google) are unavailable. Expected Results: Either the installer should not remove whatever makes those search engines available to the browser, or the installer should just delete the searchplugins directory (since leaving it is serving no purpose). This is a trunk build.
This is caused by the browser saving search plugins in the app, not in the userprofile. Happens on Mac, too. I submitted a similar bug a while back - surprised this one or that one haven't been marked as dupes.
I would love to see this fixed! Customisable search engines is a killer feature, but totally useless if they're reset everytime you update the app. Surely it's just a case of storing them in the profile folder?
taking, and targeting it for 1.0
Assignee: bugs → p_ch
Severity: normal → major
Component: Installer → Search
Summary: Installed search engines forgotten when Firebird uninstalled/reinstalled → move searchplugins directory to profile
Target Milestone: --- → Firefox1.0
*** Bug 248719 has been marked as a duplicate of this bug. ***
*** Bug 257038 has been marked as a duplicate of this bug. ***
There still needs to be a way to package search plugins globally for corporate environments after this is fixed.
Presumably the personal searchplugins folder and the global searchplugins folder are used to make the list, the only question then is which takes precedence?
(In reply to comment #7) > Presumably the personal searchplugins folder and the global searchplugins folder > are used to make the list, the only question then is which takes precedence? For consistence with other apps that load the global prefs files only if the user hasn't set one, I'd suggest that a similar thing should be done: load the user's plugins folder, but if the user has no plugins defined, fall back on the global folder. New accounts should inherit the global plugins -- for now that'd be the Google plugin. If a removal mechanism is implemented, however, some way should be provided for users to block display of installed global plugins -- that is, say, allow users to turn off the Google search plugin for their own profile but not actually remove the file from the global plugin folder so that other users who may want to search Google can still use it -- some sort of "hide this global plugin for me" flag in the user's plugin collection. I hope that makes sense!
(In reply to comment #8) > For consistence with other apps that load the global prefs files only if the > user hasn't set one, I'd suggest that a similar thing should be done: load the > user's plugins folder, but if the user has no plugins defined, fall back on the > global folder. New accounts should inherit the global plugins -- for now that'd > be the Google plugin. latest nightly Aviary builds actually contain: Google Dictionary.com Amazon.com Ebay Yahoo see bug 242586
(In reply to comment #9) > latest nightly Aviary builds actually contain: > > Google > Dictionary.com > Amazon.com > Ebay > Yahoo Is this Windows only? I grabbed a new mac build which I *think* is Aviary from 2004-08-26-10-trunk/ in case I was just too out of date and I still only see Google. I'd be happy to download another build if I picked the wrong file.
It is certainly also in the linux build for today.
(In reply to comment #10) > (In reply to comment #9) > > > latest nightly Aviary builds actually contain: > > > > Google > > Dictionary.com > > Amazon.com > > Ebay > > Yahoo > > Is this Windows only? I grabbed a new mac build which I *think* is Aviary from > 2004-08-26-10-trunk/ in case I was just too out of date and I still only see > Google. I'd be happy to download another build if I picked the wrong file. That's trunk you use, try http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-08-26-10-0.9/ for the Aviary (branch) build
Browser equivalent is bug 123315
shoudn't this be blocking the 1.0?? this breaks the posibility to add new search engines...
yeah, i had expected someone to do that before 1.0PR. Hopefilly it's still in time for 10 request ?1.0
Flags: blocking-aviary1.0?
No longer blocks: 259072
*** Bug 259072 has been marked as a duplicate of this bug. ***
*** Bug 259060 has been marked as a duplicate of this bug. ***
My bug was marked a dup of this. The big problem with the current behavior is that there is no notification of failure. Even if the information is moved to the profile, it's still a bad idea to assume it's writable and say nothing if it isn't. There should be some notification if adding the engine fails and an error message describing why it failed.
Blocks: 262161
No longer blocks: 262161
Flags: blocking-aviary1.0? → blocking-aviary1.0-
My bug was also marked as a duplicate of this. What I meant was some, any error message when the policy disallows modifying the searchplugins dir. Now the blocking flag 1.0 has been removed from this one...
*** Bug 263148 has been marked as a duplicate of this bug. ***
When search plugins are moved to the profile, how are average users gone find that directory on a Windows platform? Access to the directory is *required* to remove a plugin. Is it a bad idea to change the "Add Engines" to a "Manage Engines" item. This could open a dialog where adding, removing, changing names, changing icon, reordering and maybe even editting the .src files can be done. Or add this as a page to the Options. Adding Shift+Del is an option, but how many users know that this works in the history?
If -extensions -themes -plugins have a dialogue, it would only be logic/consistent to give searchplugins the same
well not moving it is a bad idea too only an Admin has write priviliges in the Program Files Folder (at least with Win2k, there may be some changes in XP). that means you have to run firefox as Admin to Add/Remove Searchplugins. a nice Search Plugins Manager wouldnt be a bad idea
OS: Windows XP → All
Hardware: PC → All
Since I started using Firefox on Linux, this change seems even more important. In order to add search plugins, I had to run the program as root. This should not be necessary. Also, different profiles should be able to have indivual search plugins. I agree that it would be ideal if global plugins could be set in program directory, with custom plugins in the user profiles.
Like most profile-related things this should be managable by both the user and the administrator: in the usual private setting, users want to manage their search engines (and other stuff like themes and extensions) themselves and hence this should be stored in the profile. In enterprise settings, administrators want to preconfigure search engines (and other stuff like themes and extensions) for all users on a system (instead of doing it for each user individually or messing with naked profile files) and hence this should *also* be kept in the install dir or some other place, like a global profile.
On the same note, Administrators could use some help when it comes to debugging the current problems with the searchplugins method. Since the user is not notified as to when or why adding a search plugin fails, they have absolutely nothing to tell the administrator that gets to hear about the problem.
Attached patch Patch v1.0 — — Splinter Review
1. Creates a folder "search" under pref folder. (Not "searchplugins" nor "Search Plugins") 2. Accordingly, move %profile%/search.rdf to %profile%/search/search.rdf 3. The browser uses both plugins in this folder and those in application dir ("bin/searchplugins"). 4. When a user installs a new search plugin, it will be saved in the dir in profile.
Attachment #169266 - Flags: review?(bugzilla)
Comment on attachment 169266 [details] [diff] [review] Patch v1.0 I'm not the right person to review this patch, since I'm neither a module owner nor a peer and I don't know this code. You should probably ask bsmedberg@covad.net for review and darin@meer.net super-review.
Attachment #169266 - Flags: review?(bugzilla)
Attachment #169266 - Flags: superreview?(darin)
Attachment #169266 - Flags: review?(bsmedberg)
Adding bug 123315 to depends to help tracking. Sorry for the spam.
Depends on: 123315
I am not likely to get to this review any time soon; I am focusing most of my activity on the core xulrunner. Ben or mconnor would be a better reviewer, perhaps.
Attachment #169266 - Flags: review?(bsmedberg) → review?(mconnor)
needs aviary landing keyword
(In reply to comment #31) > needs aviary landing keyword This is not an aviary landing bug. Please go reread what bugs get that keyword before you spam any more bugs with this comment.
Comment on attachment 169266 [details] [diff] [review] Patch v1.0 please re-request SR once you have a primary review.
Attachment #169266 - Flags: superreview?(darin)
Flags: blocking-aviary1.1?
It's a pity this topic doesn't develop... it's a unfortunate "violation" of the profile folder idea to save the search plugins in the installation dir. Why couldn't the installation dir just contain a "default_searchplugins" folder (which can be bundled with distros), and whenever a new profile is created, this directory is copied as "searchplugins" in the profile folder (similar to the /etc/skel/ system). Only the plugins from the profile folder are used actively, and when the user installs a new plugins, it gets installed into the profile subdir only. Shouldn't this fit all needs?
(In reply to comment #34) > Shouldn't this fit all needs? There should also be a way to disable search plugin installation for locked down installations.
*** Bug 283020 has been marked as a duplicate of this bug. ***
(In reply to comment #35) > There should also be a way to disable search plugin installation for locked down > installations. I'm not sure what the point of this would be. Preventing users from installing a particular plugin does not prevent them from using the search engine, they would merely visit the site to do the search. To lock down users to prevent them from accessing a particular search engine, you would use a firewall and/or a proxy. What would be the point in not permitting them to install the Amazon plugin if they could just visit amazon.com to accomplish the same thing? If you configure the firewall or web proxy to block access to amazon.com, then you don't need to block installation of the search plug-in.
(In reply to comment #37) > What would be the point in not permitting them to install the Amazon plugin if > they could just visit amazon.com to accomplish the same thing? If you configure > the firewall or web proxy to block access to amazon.com, then you don't need to > block installation of the search plug-in. Well, assume that firefox is running on a public terminal. If ppl. are installing more and more search plugins the chooser could get really crowded. It should be possible to limit this without stopping users from visiting any search-engine. btw: Even if you remove access to google.com though a firewall, users would still be able to install the search plugin, which won't make any sense anymore, if users won't be able to use it.
*** Bug 285299 has been marked as a duplicate of this bug. ***
Whiteboard: [asaP1]
(In reply to comment #37) > (In reply to comment #35) > > There should also be a way to disable search plugin installation for locked down installations. > > I'm not sure what the point of this would be. The point is for corporate installations that need to be locked down from anything being installed, including searchplugins in the user's profile. It has nothing to do with restricting access to particular search engines.
(In reply to comment #40) > (In reply to comment #37) > > (In reply to comment #35) > > > There should also be a way to disable search plugin installation for locked > down installations. > > > > I'm not sure what the point of this would be. > > The point is for corporate installations that need to be locked down from > anything being installed, including searchplugins in the user's profile. It has > nothing to do with restricting access to particular search engines. Exactly. Howeever, this has absolutely NOTHING to do with this bug! This bug is about where the search pugins should be installed. The ability to create a locked-down configuration where the user is unable to add plugins, search-plugins, extensions or themes is an entirely seperate issue which is really completely unrelated to whcich directory the search-plugins install to. Extensions and themes already install to the user profile, so if installing to the user profile makes it impossible for you to lock down your config you have more to worry about than search-plugins.
Blocks: 289826
(In reply to comment #41) > (In reply to comment #40) > > (In reply to comment #37) > > > (In reply to comment #35) > > > > There should also be a way to disable search plugin installation for locked > > down installations. > > > > > > I'm not sure what the point of this would be. > > > > The point is for corporate installations that need to be locked down from > > anything being installed, including searchplugins in the user's profile. It has > > nothing to do with restricting access to particular search engines. > > Exactly. Howeever, this has absolutely NOTHING to do with this bug! This bug > is about where the search pugins should be installed. Actually it somewhat does, as currently running as a user without write permissions to the program directory accomplishes the same thing. When the extension mechanism was redesigned, the option was given to disable installation of extensions. It is easier to implement things from the start than as an afterthought. But to prevent further spam of this bug, I've filed Bug 289826 on this. > Extensions and themes already install to the user profile, so if installing to > the user profile makes it impossible for you to lock down your config you have > more to worry about than search-plugins. That's what locked prefs are for in custom packages. It is quite possible to lock down a configuration, it just takes some work.
No longer blocks: 289826
The point with regard to locked down installations is this: if you want to lock things for many users you want to be able to change and set it for many users at once. Therefore, even if the locking feature itself is not the point here, it would be good to still have the option to set the search plugins in the program path in addition to the profile path, so that predefining is easier. So when adding support for installation in the profile, this should not fully remove the possibility to install in the program path. Unfortunately exactly this happened with the extensions and themes, so it is very hard now for an administrator to preinstall themes and extensions for all users, whether you want to lock it afterwards or not. To sum this up: there should be a patch to install search engines in the profile by default, but there should still be a way to install/change them in the program directory.
(In reply to comment #43) How do locked down installations handle extensions and bookmarks? Surely the logical thing to do would be for searchplugins to work in the same way.
We want a solution for this in time for 1.1, especially for Linux. At the least (stopgap) we need a way to disable UI/backend for adding searchplugins if the user can't do it. There's also a lack of useful feedback on failure, etc.
Flags: blocking-aviary1.1? → blocking-aviary1.1+
I don't know if it is the Debian port, but on my Linux PC Firefox installs search plugins in the user profile. It worked this way at least from the Debian package mozilla-firefox 1.0.1-1 (maybe early?).
(In reply to comment #46) > I don't know if it is the Debian port, but on my Linux PC Firefox installs > search plugins in the user profile. It worked this way at least from the Debian > package mozilla-firefox 1.0.1-1 (maybe early?). Yes, it's Debian that "messed" this up for you. To verify, download the original MoFo Fx and double check.
for the record, i do not like this patch. nor do i like that the blocking annotation which *clearly* exists on this bug is being ignored.
I'm sure you're making a valid point. But is there any chance of non-developers (such as myself) EVER learning what these flags mean? See bug 183758.
*** Bug 285169 has been marked as a duplicate of this bug. ***
*** Bug 293380 has been marked as a duplicate of this bug. ***
Comment on attachment 169266 [details] [diff] [review] Patch v1.0 better patch in bug 123315 that has r+sr already.
Attachment #169266 - Flags: review?(mconnor)
*** Bug 294741 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
Blocks: 232272
Blocks: 289826
Blocks: 297306
*** This bug has been marked as a duplicate of 123315 ***
Status: NEW → RESOLVED
Closed: 19 years ago
No longer depends on: 123315
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0-
Resolution: --- → DUPLICATE
*** Bug 261611 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → search
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: