move searchplugins directory to profile

RESOLVED DUPLICATE of bug 123315

Status

()

Firefox
Search
--
major
RESOLVED DUPLICATE of bug 123315
15 years ago
12 years ago

People

(Reporter: Bill Mason, Assigned: Pierre Chanial)

Tracking

unspecified
Firefox1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [asaP1])

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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.

Comment 1

15 years ago
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.

Comment 2

15 years ago
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?
(Assignee)

Comment 3

14 years ago
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
(Assignee)

Comment 4

14 years ago
*** Bug 248719 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

14 years ago
*** Bug 257038 has been marked as a duplicate of this bug. ***

Comment 6

14 years ago
There still needs to be a way to package search plugins globally for corporate
environments after this is fixed.

Comment 7

14 years ago
Presumably the personal searchplugins folder and the global searchplugins folder
are used to make the list, the only question then is which takes precedence?

Comment 8

14 years ago
(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

Comment 10

14 years ago
(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.

Comment 11

14 years ago
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

Comment 14

14 years ago
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?
Blocks: 259072

Updated

14 years ago
No longer blocks: 259072

Comment 16

14 years ago
*** Bug 259072 has been marked as a duplicate of this bug. ***
No longer blocks: 259060
*** Bug 259060 has been marked as a duplicate of this bug. ***

Comment 18

14 years ago
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.

Updated

14 years ago
Blocks: 262161

Updated

14 years ago
No longer blocks: 262161
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 19

14 years ago
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. ***

Comment 21

14 years ago
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

Comment 23

14 years ago
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

Updated

14 years ago
OS: Windows XP → All
Hardware: PC → All

Comment 24

14 years ago
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. 

Comment 26

14 years ago
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.
Created attachment 169266 [details] [diff] [review]
Patch v1.0

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.

Updated

14 years ago
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

Comment 30

14 years ago
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)

Comment 31

14 years ago
needs aviary landing keyword
(Reporter)

Comment 32

14 years ago
(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 33

14 years ago
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)

Updated

14 years ago
Flags: blocking-aviary1.1?

Comment 34

14 years ago
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?

Comment 35

14 years ago
(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.

Comment 36

14 years ago
*** 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.

Comment 38

14 years ago
(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. ***

Updated

13 years ago
Whiteboard: [asaP1]

Comment 40

13 years ago
(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.

Updated

13 years ago
Blocks: 289826

Comment 42

13 years ago
(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.

Comment 44

13 years ago
(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+

Comment 46

13 years ago
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?).

Comment 47

13 years ago
(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.

Comment 48

13 years ago
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.

Comment 49

13 years ago
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.

Comment 50

13 years ago
*** Bug 285169 has been marked as a duplicate of this bug. ***

Comment 51

13 years ago
*** 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. ***

Updated

13 years ago
Blocks: 163993

Updated

13 years ago
No longer blocks: 163993

Updated

13 years ago
Blocks: 232272

Updated

13 years ago
Blocks: 289826

Updated

13 years ago
Blocks: 297306
No longer blocks: 297306

Comment 54

13 years ago

*** This bug has been marked as a duplicate of 123315 ***
Status: NEW → RESOLVED
Last Resolved: 13 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. ***

Updated

13 years ago
QA Contact: bugzilla → search
No longer blocks: 289826
You need to log in before you can comment on or make changes to this bug.