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
(deleted), 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 (deleted) — — 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: