123315 - Search plugins [engines] should be installed in the user's profile directory

Status: RESOLVED FIXED

(SeaMonkey :: Search, defect, P2)

Description

[Carey Evans]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.8+) Gecko/20020129
BuildID:    2002012921

I am unable to install search plugins like those from
http://sherlock.mozdev.org/ as a normal user. strace shows that Mozilla is
trying to save the .src and .gif files to /usr/local/mozilla/searchplugins/,
which is only writable by root, and is on a read-only partition anyway.

If I download the files and copy them to that directory manually as root, the
Search plugin appears in the drop-down list when I restart Mozilla as a normal user.

Reproducible: Always
Steps to Reproduce:
1. Install Mozilla as root.
2. Run Mozilla as a normal user, and go to
<http://sherlock.mozdev.org/download.html>.
3. Click on one of the search plugins, and approve installation.
4. Look for the plugin in the Search sidebar.

Actual Results:  The search plugin does not appear in the Search sidebar.

Expected Results:  The search plugin should appear in the Search sidebar. I
should at least get an error saying why. Better would be for the plugin to be
saved in my profile directory.

Comment 1

[R.K.Aa.]

related/dup: bug 101245, bug 29741

Comment 2

[Carey Evans]

This happens to me with build 2002020208 under Windows 2000 Professional as well
- as a normal user (not Power User), trying to install a search plugin fails
silently, but as Administrator the plugin installs immediately.

Comment 3

[Samir Gehani]

*** This bug has been marked as a duplicate of 101245 ***

Comment 4

[Carey Evans]

Although bug 101245 has been fixed, I still can't install search plugins
automatically or manually as a normal user, under Windows 2000 or Linux.  I've
tested using 0.9.9, and build 2002031903.

Comment 5

[Erich 'Ricky' Iseli]

Confirming. The ~/.mozilla/searchplugins method (similar to the
~/.mozilla/plugins method described by bug 45699, comment #5) still doesn't
work. Setting severity to Major because it is indeed a major loss of function.
Some people don't have access to the root account, and then they cannot use
custom search plugins at all.

Comment 6

[Erich 'Ricky' Iseli]

revision: bug 101245, comment #5 describes how plugins can be put in the
~/.mozilla/plugins directory, not bug 45699. Sorry for the spam.

Comment 7

[Jesse Ruderman]

Search plugins should be installed in the profile directory by default.  Because
they're installed in the bin directory, I lose them each time I install a new
build, since I install each new build in a new directory.

Comment 8

[Erich 'Ricky' Iseli]

*** Bug 157182 has been marked as a duplicate of this bug. ***

Comment 9

[Erich 'Ricky' Iseli]

*** Bug 161052 has been marked as a duplicate of this bug. ***

Comment 10

[Erich 'Ricky' Iseli]

Changing summary. Old summary: tries to install search plugins in unwritable
installation directory

Comment 11

[Pete Zha]

Does anyone know is there any updates of this bug?

Comment 12

[Jay Yan]

By configuring MOZ_PLUGIN_PATH, user can put plugins anywhere he likes, can we
add MOZ_SEARCHPLUGIN_PATH for user to put his search engines anywhere he likes?

Comment 13

[Pete Zha]

adding an entry in preference setting is another solution. User can add
additional path to let mozilla search the "searchplugins". This way, the setting
will depend on user's profile.

Comment 14

[Benjamin Smedberg]

Unless you have objections, I would like to take this bug... can we ask in the
install dialog  whether to install the sherlock in their profile or in the
mozilla installation? That way if you upgrade mozilla you don't have to manually
copy sherlocks.

Comment 15

[Dan Price]

From a similar but slightly different perspective: this makes much harder
for me to develop and test a plugin which I subsequently deploy to many
users at a multi-user installation, since I can't start out by having
private plugins without doing a whole separate installation of mozilla.

Firebird really highlighted to me how useful these plugins are.

Addressing comment #7: I think the right way to handle this is to find
the global searchplugins first, then look at the user's set, handling
duplicates as appropriate.

Comment 16

[alanjstr]

I'm not familiar enough with the Firebird search backend to know if a seperate
bug should be filed.

Comment 17

[Peter Lairo]

Will fixing this bug (product: browser) also fix the same bug in firebird
(product: firebird)? 

It seems a *separate Firebird bug* (?) might help focus the efforts somewhat, as
the searbar in FB is more visible/used and the MozSuite / FB Search Plugins may
be somewhat different. :-\

Comment 18

[Matthew A. McGuigan]

FB and Moz use the same search backend and the same search plugins.  Fixing this
in either should fix it in both.  However, since reading this
http://www.mozillazine.org/talkback.html?article=4104 , I don't know whether
another bug should be filed or not.  

Comment 19

[Scott Gifford]

One of the more annoying aspects of this bug is that when the install fails due
to permissions problems, it fails silently.  I flailed around for about half an
hour trying to get search plugins to install before realizing it was a
permissions problem.  I've just opened bug 237573 which addresses this silent
failure, independent of whether a way is provided for unprivileged users to
install their own plugins.

Comment 20

[Benjamin Smedberg]

I am working on other things, and don't have the time to fix this. Feel free to
take it: I'll be happy to review patches.

Comment 21

[David Hallowell]

Might as well have a shot at this in a few weeks time

Comment 22

[PikeUK]

*** Bug 248404 has been marked as a duplicate of this bug. ***

Comment 23

[Jaap A. Haitsma]

*** Bug 251390 has been marked as a duplicate of this bug. ***

Comment 24

[Stephen Smith]

I'd like to see a bug fix land for this issue before Firefox 1.0. It's something
can cause a lot of problems for end-users, especially when considered in
conjunction with bug <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=248719">248719</a>. 

Comment 25

[Robin Lu]

Attachment: patch

with this patch, mozilla can save/load search plugins from profile directory.
For example, in linux it is ~/.mozilla/searchplugins . If there are conflict in
user directory and product directory, the search engines in user directory will
override the ones in product directory. I think this method is easier to
implement while still reasonable. 
When a search engine is going to be downloaded, there is a checkbox in the
prompt dialog, you can check it if you want the search engine to be downloaded
to the user's profile dir.
I only changed the UI of mozilla. If you want firefox to save search enigine to
user profile dir, you can change the preference
"browser.search.save_in_user_dir" to true to make it work.

Comment 26

[timeless]

Comment on attachment 164539 [details] [diff] [review]
patch

don't do it this way. please see the way we handle browser plugins.

Comment 27

[Robin Lu]

timeless, could you state a bit clearly what is exactly wrong with the patch?
Which aspect should I follow the browser plugin way and why? Just tell me don't
do that doesn't make any sense.

Comment 28

[Robin Lu]

Attachment: patch

fix in both mozilla and firefox

Comment 29

[timeless]

instead of adding a series of items with annoying fallbacks, provide a single
key which combines the multiple possible sources into a single enumerator, see
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsAppFileLocationProvider.cpp#575

Comment 30

[Robin Lu]

(In reply to comment #29)
> instead of adding a series of items with annoying fallbacks, provide a single
> key which combines the multiple possible sources into a single enumerator, see
> http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsAppFileLocationProvider.cpp#575
browser plugins are different from search plugins. Browser plugins are installed
by users, which may be installed into various directory. Search plugins are
installed by browser itself. Browser has full control on where the search
plugins are. I don't see the requirement for multiple search plugin directories
is nessesary.

Comment 31

[Peter Weilbacher]

(In reply to comment #30)
> Search plugins are installed by browser itself. 
> Browser has full control on where the search plugins are.

Unless I am severely mistaken and search plugins are not the *.src files under
searchplugins/ your statement is incorrect. I never install search plugins with
the browser, but instead every time I install a new build I unzip my selection
of *.src (and related *.gif) files into searchplugins/ where the browser picks
them up on the next start.

Comment 32

[Robin Lu]

(In reply to comment #31)
> searchplugins/ your statement is incorrect. I never install search plugins with
> the browser, but instead every time I install a new build I unzip my selection
> of *.src (and related *.gif) files into searchplugins/ where the browser picks
> them up on the next start.
It's "copy". What I mean is "install". If you know how to copy those files, you
mostly don't need multiple directories either.

Comment 33

[Steffen Wilberg]

Do we have to ask the user where to store the searchplugins, as the patch does?
We're not asking where to store extensions either. On Firefox and Thunderbird,
that is. I'd suggest to always store newly installed searchplugins in the
profile folder, but also use the ones in the application folder because of
compatibility with old profiles and manageability - think of a corporate
environment. These two locations should be sufficient.

Comment 34

[Robin Lu]

In fact, unless you change it, it always keeps your last choice. So, you  don't
need to care about it if you don't want to.

Comment 35

[timeless]

robin: you're wrong.

on macosx there's a global folder (or perhaps two) for sherlock plugins, we
should pull those in addition to the ones in the app folder and the user profile
folder, as such an enumerator is the way to go.

Comment 36

[Robin Lu]

timeless: please see the bug description carefully. This bug concerns where to
install. What you are talking about is where to load. We don't need multiple dir
for users to install their search plugins. It just confuses them.

If you think there's nessesary to load search plugins from multiple dir, please
file another bug.

Comment 37

[Benjamin Smedberg]

This is an official owner's decision that I discussed with Ben Goodger a while
back, so please listen up:

The desired behavior is that search plugins installed by the user would be
installed into the profile. There should not be UI asking where the user wishes
to install the searchplugin.

It should be possible for distributors to ship search plugins in the application
searchplugins/ directory. Thus a directoryservice list is necessary, a patch
will not be accepted without it.

Comment 38

[Robin Lu]

Attachment: patch

search engine can be saved to user's profile directory, for example, in unix
~/.mozilla/searchplugin
search engine can be loaded from mozilla installation directory, user's profile
and the directories setting in "MOZ_SEARCH_ENGINE_PATH".

Comment 39

[timeless]

at some point we'll want to add support for the mac directories

Comment 40

[Robin Lu]

if you can point me what to add, maybe I can try it on my powerbook.

Comment 41

[timeless]

sherlock's main location is: /System Folder/Internet Search Sites/Internet/
interarchy's is: /System Folder/Interarchy/Internet Search Sites/
interarchy supports both, i'm not sure whether we should suck in interarchy's or
not.

i also haven't found a reference for a user Internet Search Sites folder, i'd
expect one to be supported, but i'm tired.

Comment 42

[TGOS]

@timeless:

I have idea what you are talking about, when talking about Mac directories. On
the Mac search plugins belong exactly where they belong on Linux or UNIX.

Storing them anywhere else makes no sense whatsoever. This is not comparable to
plugins! Storing plugins in a more central place makes sense, as all browser
share the same plugins on the Mac. But no browser except Mozilla/Firefox will
understand the Mozilla/Firefox search plugins, so it makes no sense to store
them outside the profile directory.

Comment 43

[timeless]

[e-mail]: excuse me, about .src is an apple file format, we support
their files because we designed our search support based on it. we absolutely
support their files and therefore should support whatever plugins the user has
picked for the system.

Comment 44

[Carey Evans]

Mozilla's search plugins are based on the Sherlock 2 site search file format. 
However, Mac OS X (since 10.2, at least) comes with Sherlock 3, which doesn't
support Sherlock 2 plugins, and Mozilla doesn't support Sherlock 3 plugins.

If Mozilla should look for search plugins installed by Sherlock 2, Watson,
Interarchy, etc., please make that a separate bug.

Comment 45

[Robin Lu]

It seems like that the code exists for check the internet search folder in
ClassicDomain. I don't have Classic installed so that I can't check if it
already support sherlock 2.

Comment 46

[Benjamin Smedberg]

Comment on attachment 165230 [details] [diff] [review]
patch

For some reason I thought this was a Firefox patch, so I am not a peer of this
code. When asking for review again, try Neil Rashbrook.

However, I am against adding any more cruft to nsAppDirectoryServiceDefs.h/cpp.
That is an obsolete file that needs to be dealt with. To implement this patch
properly, seamonkey needs to use a directory service provider like the new
toolkit does, so that we don't have to throw all these file locations into
XPCOM.

Comment 47

[Robin Lu]

The patch works for both firefox and mozilla.
I put the implemention in
nsAppDirectoryServiceDefs.h/nsAppFileLocationProvider.cpp because the directory
provider for current search plugins is there. If this provider will be
refactoried in the future, to put the two dirctories together right now does no
harm.

Comment 48

[kozaki]

This way (have to be root to install search plugins) is non-sense, especially
for newbies Linux users on Firefox.
I'm trying my best to make it possible for them *not have to become root* to use
their OS on a regular basis.
This bug is a real unsecure one.

I tried to do as mentionned by Robin Lu
But i have no "browser.search.save..." line into Firefox 1.0 prefs (that's into
about:config).
When a search engine is going to be downloaded, there is *no* checkbox in the
prompt dialog.

Reproducible: Always
Steps to Reproduce:
1. Install Mozilla Firefox as root (RPM package).
2. Run Mozilla as a normal user, and go to <http://mycroft.mozdev.org/>.
3. Click on one of the search plugins, and approve installation.
4. Look for the plugin in the Search sidebar.

Actual Results:  The search plugin does not appear in the Search sidebar.

Expected Results:  The search plugin should appear in the Search sidebar. One
should at least get an error saying why. Better would be for the plugin to be
saved into user's profile directory.
Or when a search engine is going to be downloaded, there should be a checkbox in
the prompt dialog, asking the user where to install it.

Thanks for your help.

kozaki <http://c.laloy.fre.fr/howtos>

Comment 49

[Robin Lu]

kozaki,

if possible, please use my latest patch and try. It will help browser to install
search plugin into profile directory by default. you don't need to set any
preferenc.

Comment 50

[:Gavin Sharp [email: [e-mail]]]

*** Bug 235600 has been marked as a duplicate of this bug. ***

Comment 51

[mozilla-bugs]

Robin Lu's most recent patch does not apply cleanly to firefox 1.0, but I was
able to apply it by hand.  I can now add search plugins in linux as a non-root
user by clicking installation links.  However, the patch installs search plugins
to ~/.mozilla/searchplugins/, NOT in profile directory,
~/.mozilla/firefox/profilename/searchplugins/, as I would expect.  I think this
still means that multiple firefox profiles (and I suspect multiple mozilla
profiles) will all use the same search plugins.  This could be a problem for
some users.

Still, the patch is a huge improvement and was worth the recompile.

Comment 52

[Rob G]

No one has mentioned Windows XP.  The same behavior described occurs on Windows
XP SP2 using FireFox 1.0 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0).

If I'm reading the posts correctly, the current behavior of writing to the
program directory and not to the user's profile directory violates the principal
of least privilege.  It seems pretty hard to believe that this bug was
originally reported almost 3 years ago and has not been fixed yet.  Am I reading
the post dates wrong?

Comment 53

[Rob G]

After reading my post again it sounds like it could be taken as a negative
comment.  It wasn't meant to be.

Comment 54

[Robin Lu]

Attachment: patch

now search plugins are saving to user's profile directory.

Comment 55

[timeless]

Comment on attachment 171600 [details] [diff] [review]
patch

a few random points in no particular order
* don't use tabs

#define NS_USER_SEARCH_DIR			"UsrSrchPlugns"
is in the wrong place, and doesn't match the place where it should be
if you look a few lines below, you should see:

// Files and directories which exist on a per-profile basis
followed by a list of things, like
#define NS_APP_USER_CHROME_DIR			"UChrm"
which is a pair to "AChrom"

i think it'd be better if you removed the tabs from the function you're
changing. esp InternetSearchDataSource::DeferredInit

you should remove the XP_MAC bit from DeferredInit
move it into the enumerator
once you move that other block out of deferredinit, you basically have
rewritten the function, so there's really no harm in fixing the tabs
the xp_mac code into the enumerator. that's the right thing to do

change the |if (!gEngineListBuilt)| to:
if (gEngineListBuilt)
    return NS_OK;

making that change reduces the level of indentation and makes the code easier
to read

you should also move gEngineListBuilt to just above PRBool hasMore; (or maybe
later)
that way, if the service is unavailable and doesn't feel like building, it
won't say it's inited

one more thing. make sure that InternetSearchDataSource deals with profile
change notifications properly. the old code didn't care, since the info didn't
change between profiles. you're breaking that invariant.

Comment 56

[Robin Lu]

(In reply to comment #55)
> * don't use tabs
I don't like tabs either. I just want to keep the format within context and I
think it is better to do so than to add just another format.
 
> #define NS_USER_SEARCH_DIR			"UsrSrchPlugns"
> is in the wrong place
I'll move it down.


> i think it'd be better if you removed the tabs from the function you're
> changing. esp InternetSearchDataSource::DeferredInit
> 
> you should remove the XP_MAC bit from DeferredInit
> move it into the enumerator
> once you move that other block out of deferredinit, you basically have
> rewritten the function, so there's really no harm in fixing the tabs
> the xp_mac code into the enumerator. that's the right thing to do
I need to add a XP_MAC in the enumerator because nsPathsDirectoryEnumerator is
not supported in XP_MAC. But I have no intension to remove the XP_MAC in
DeferredInit. I think it is very clear and had better not be in the same
enumeration as above.
 
> change the |if (!gEngineListBuilt)| to:
> if (gEngineListBuilt)
>     return NS_OK;
> 
> making that change reduces the level of indentation and makes the code easier
> to read
Thanks for review the code that was not written by me. Good comment anyway.

> you should also move gEngineListBuilt to just above PRBool hasMore; (or maybe
> later)
I will do so.

> one more thing. make sure that InternetSearchDataSource deals with profile
> change notifications properly. the old code didn't care, since the info didn't
> change between profiles. you're breaking that invariant.
It's a real problem. I will fix it

Thanks for your comment, timeless. However, you don't need   to be so eager to
add the "review -" on my patch, either when I haven't requested any review or
don't reqeust review from you at all. I am able to accept good comments and
revise my patch. I can cancel the review by myself if there's any good comment.
Your "review -" can't make your comments more reasonable. So, please don't do
that unless I request review from you. 

Comment 57

[timeless]

robin: i'm a peer. i'm well within my rights to r- a patch in my module.

Comment 58

[Ryan VanderMeulen [:RyanVM]]

Robin, are you still working on this?

Comment 59

[Robin Lu]

I am sorry I don't have much time recently. Feel free to take this bug.

Comment 60

[Daniel Veditz [:dveditz]]

Plussing for next releases per drivers

Comment 61

[Mike Connor [:mconnor]]

Attachment: patch addressing comments

Comment 62

[timeless]

Comment on attachment 182796 [details] [diff] [review]
patch addressing comments

>+#define NS_APP_USER_SEARCH_DIR                  "UsrSrchPlugns"
please use "USrch" (or something like it, the items are supposed to be short).

i'll file a bug for moving the mac code against myself after this is fixed.

Comment 63

[[e-mail]]

Comment on attachment 182796 [details] [diff] [review]
patch addressing comments

>+        // read in category list
>+        rv = GetCategoryList();
>+    }
I don't think this belongs inside the loop... sr=me with this fixed.

>+#ifdef    XP_MAC
So you (timless) are planning to fix this later?

> nsresult
> InternetSearchDataSource::GetSearchFolder(nsIFile **searchDir)
> {
>   NS_ENSURE_ARG_POINTER(searchDir);
>   *searchDir = nsnull;
> 	
>   nsCOMPtr<nsIFile> aDir;
>-  nsresult rv = NS_GetSpecialDirectory(NS_APP_SEARCH_DIR, getter_AddRefs(aDir));
>+  nsresult rv = NS_GetSpecialDirectory(NS_APP_USER_SEARCH_DIR, getter_AddRefs(aDir));
>   if (NS_FAILED(rv)) return rv;
>   
>   *searchDir = aDir;
>   NS_ADDREF(*searchDir);
>   return NS_OK;
> }
So, how is this different to
nsresult
InternetSearchDataSource::GetSearchFolder(nsIFile **searchDir)
{
  return NS_GetSpecialDirectory(NS_APP_USER_SEARCH_DIR, searchDir);
}
;-)

>+    else if (nsCRT::strcmp(prop, NS_APP_USER_SEARCH_DIR) == 0)
Not exactly the best file for this, but then where is? :-/

Comment 64

[Robin Lu]

does this patch deal with profile change notifications addressed in comment #55?

Comment 65

[Daniel Veditz [:dveditz]]

How are searchplugin *updates* handled with this patch? If one of the default
set required a plugin update would the update go into the users profile, or
attempt to replace the existing global one and fail?

This patch does not give users the ability to remove an unwanted global search
plugin either. Assuming we add UI for that as requested in other bugs the user
would be able to remove some plugins but not others. Either we completely
mystify them, or we have to design a more complicated UI to convey the
difference, or save

Both problems would be solved by treating search plugins as we do other default
profile settings (e.g. bookmarks): use the global files as a starter-set to be
copied to the profile. Once copied the existing mechanism works as-is after a
simple change to point at the new location.

One downside is that additional plugins delivered with future program updates
wouldn't be seen by existing profiles.

Comment 66

[Daniel Veditz [:dveditz]]

(In reply to comment #65)
> would be able to remove some plugins but not others. Either we completely
> mystify them, or we have to design a more complicated UI to convey the
> difference, or save

"... a deleted/hidden state with the search engine ping information in
localstore.rdf (or a pref)." Which is not such a bad idea actually. So multiple
locations as in this patch is probably the way to go as long as the update bit
works.

Comment 67

[Mike Connor [:mconnor]]

Given that there's a lot more to do with search, in general, I'm not so worried
about the remove case at present.  There may be practical things we can do with
reordering/hiding in the 1.1 timeframe, but lets not go too far until we've
decided where we're going with search in general.

http://wiki.mozilla.org/Firefox:2.0_Search_Service talks about requirements for
a future set of changes to the search service, and this is something I want to
get going in the 1.5 cycle.

I think the update mechanism is already broken in a number of ways without this
patch, but I'll test update today to be sure.

Comment 68

[Phil Ringnalda (:philor)]

*** Bug 294438 has been marked as a duplicate of this bug. ***

Comment 69

[Asa Dotzler [:asa]]

*** Bug 232638 has been marked as a duplicate of this bug. ***

Comment 70

[Mike Connor [:mconnor]]

Attachment: patch (unbitrotted)

Comment 71

[Benjamin Smedberg]

Comment on attachment 187520 [details] [diff] [review]
patch (unbitrotted)

With this patch I'm pretty sure you're going to end up reading
NS_APP_SEARCH_DIR *twice* for seamonkey and *three* times for firefox:

the internetsearchservice reads NS_APP_SEARCH_DIR directly, and then
NS_APP_SEARCH_DIR_LIST:

http://lxr.mozilla.org/mozilla/source/xpfe/components/search/src/nsInternetSear
chService.cpp#989

And then the browserdirectoryprovider returns NS_SUCCESS_AGGREGATE_RESULT,
which means that it will return itself *plus* the dirlist returned by
appfilelocationprovider.

Finally, there is no need to return a file location for NS_APP_USER_SEARCH_DIR
from both appfilelocationrprovider and browserdirectoryprovider.

Comment 72

[Mike Connor [:mconnor]]

Attachment: patch addressing review comments

Ok, this should only touch each directory once, and its a lot cleaner, and
keeps appdir searchplugins on top, which seems to make the most sense

Comment 73

[Peter Lairo]

(In reply to comment #72)
> keeps appdir searchplugins on top

Would it make sense to place a *dividing line* between the appdir searchplugins
and the userdir searchplugins? This would avoid the seeming inconsistency of the
searchplugins not being listed alphabetically from top to bottom.

[(G)        ]
+---------------+
| a             |
| b             |  <--- appdir searchplugins
| c             |
+---------------+  <--- *dividing line*
| a             |
| b             |  <--- userdir searchplugins
| c             |
+---------------+
| Add Engines...|
+---------------+

Comment 74

[u49640]

(In reply to comment #73)
> 
> Would it make sense to place a *dividing line* between the appdir searchplugins
> and the userdir searchplugins? 

IMO no. (its just confusing)

Windows NT4 had this for the Startmenu items (All users and this user) and it
was dropped to a combined List in Win2k and higher.

just sort them all together and its fine.

Comment 75

[Frank]

(In reply to comment #73)

> Would it make sense to place a *dividing line* between the appdir searchplugins
> and the userdir searchplugins? This would avoid the seeming inconsistency of the
> searchplugins not being listed alphabetically from top to bottom.

I think you should see bug #232272 for this.

Comment 76

[TGOS]

In reply to comment #74)

And because MS does it like that, it's good? I think it's highly annoying. You
open your startmenu folder and just can't find an entry... oh right, it's all
users! You move something aside and get stupid question "are you sure you ... it
applies to all users". Very annoying. And most annoying, you get other users
asking "Hey, where did my app go" when you decided to move it somewhere else
because YOU want to have it there in YOUR menu. So taking Windows as a pargon is
rather bad for most GUI decissions.

I don't know what speaks against such a line, except that MS is not using it
anymore in startmenu (what I don't really consider an argument)

Comment 77

[Grayson Mixon (ColdFusion650)]

(In reply to comment #73)
> Would it make sense to place a *dividing line* between the appdir searchplugins
> and the userdir searchplugins? This would avoid the seeming inconsistency of the
> searchplugins not being listed alphabetically from top to bottom.

i have an idea. just put all the search plugins in the profile directory. cause
i delete 4 of the default plugins, cause i dont use them and they just clutter
up the list. if all of them were in the profile directory, i could delete the
ones i dont use, without affecting other users. just a suggestion. i dont see
why the search plugins should reside in 2 different places when they could just
reside in 1.

Comment 78

[Peter Lairo]

(In reply to comment #74)
> IMO no. ([a dividing line is] just confusing)

The patch "keeps appdir searchplugins on top"! As long as that is the case, then
a dividing line *reduces* confusion because the two sortings are visually
delineated.

If Mike were to "sort them all together" (as you suggested), then obviously we
wouldn't need a dividing line.

BTW: Post-WinNT it is possible to rearrange the Start Menu items. The
searchplugins are static and sorted alphabetically. Apples and oranges.

(In reply to comment #75)
Bug 232272 is about "managing" the searchplugings (rearranging, deleting), of
which user-adding of dividing lines anywhere is only a small subpart, and
unrelated to the current *static* division between appdir and userdir searchplugins.

Comment 79

[Mike Shaver (:shaver emeritus)]

Comment on attachment 187603 [details] [diff] [review]
patch addressing review comments

>+    else if (nsCRT::strcmp(prop, NS_APP_USER_SEARCH_DIR) == 0)
>+    {
>+        rv = NS_GetSpecialDirectory(NS_APP_USER_PROFILE_50_DIR, _retval );
>+        if (NS_FAILED(rv)) return rv;
>+        return (*_retval)->AppendNative(SEARCH_DIR_NAME);
>+    }
>     else if (nsCRT::strcmp(prop, NS_APP_INSTALL_CLEANUP_DIR) == 0)
>     {   

This creates else-after-return, an undesirable nonsequitur.  Please remedy!

>+  rv = NS_GetSpecialDirectory(NS_APP_USER_SEARCH_DIR, getter_AddRefs(outFile));
>   if (NS_FAILED(rv))
>     return rv;
> 
>+	PRBool exists; 
>+	rv = outFile->Exists(&exists); 
>+	if (NS_FAILED(rv)) return(rv);
>+	if (!exists)
>+	{
>+		rv = outFile->Create(nsIFile::DIRECTORY_TYPE, 0755);
>+		if (NS_FAILED(rv)) return(rv);
>+	}
>+
>+

Whacked indentation here.

Fix those two, and sr=shaver.

Comment 80

[Grayson Mixon (ColdFusion650)]

i still think that putting all of the search plugins in the profile directory
would be the best way.

Comment 81

[Mike Connor [:mconnor]]

checked in.

Comment 82

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050629
Firefox/1.0+ ID:2005062909

verified
adding an engine adds the searchplugins directory to profile and adds the engine

Comment 83

[manc39]

This fix has landed, so why are the trunk builds still coming complete with
default searchplugins? 

Surely one of the reasons for this bug was so a Firefox update wouldn't mess
around with a user's searchplugins?

Comment 84

[Benjamin Smedberg]

of course we're shipping with default searchplugins. The point of this exercize
was to allow users to add profile-based searchplugins.

Comment 85

[Adam Guthrie]

*** Bug 300274 has been marked as a duplicate of this bug. ***

Comment 86

[Worcester12345]

(In reply to comment #84)
> of course we're shipping with default searchplugins. The point of this exercize
> was to allow users to add profile-based searchplugins.

Yes, but do the defaults override the users' set ones?

Comment 87

[Hero Wanders]

Why isn't the searchbar realized as an optional but default extension for all
new profiles and which may even be uninstalled?
I'm not in the development of Firefox but I think this is possible.

Comment 88

[Jaime Mitchell (use [e-mail] for email)]

(In reply to comment #87)
> Why isn't the searchbar realized as an optional but default extension for all
> new profiles and which may even be uninstalled?
> I'm not in the development of Firefox but I think this is possible.

This comment has no relevance to this bug please keep comments on topic. 
You can remove the search bar by right clicking selecting customise... and then
dragging the search box from the toolbar. 
(sorry for the bugspam)

Comment 89

[Jennifer]

Was this applied to the Mac version also? I just tried moving the plugins to my
profile and they seem to be picked up by the browser (at long last!). It even
places newly-added plugins in the profile folder and not the application. If so,
shouldn't it be listed as "ALL" (hopefully the rest of the platforms got it too?)

Comment 90

[Adam Guthrie]

*** Bug 308550 has been marked as a duplicate of this bug. ***

Comment 91

[Adam Guthrie]

*** Bug 311064 has been marked as a duplicate of this bug. ***

Comment 92

[Phil Ringnalda (:philor)]

*** Bug 311361 has been marked as a duplicate of this bug. ***

Comment 93

[Dave Townsend [:mossop]]

*** Bug 314137 has been marked as a duplicate of this bug. ***

Comment 94

[Adam Guthrie]

*** Bug 314298 has been marked as a duplicate of this bug. ***

Comment 95

[:Gavin Sharp [email: [e-mail]]]

*** Bug 314499 has been marked as a duplicate of this bug. ***

Comment 96

[rowlands]

Firefox 1.5 installer deleted my custom search plugins. Yes, I know, I should have had a backup, mea culpa, etc. This bug is not fixed, and should be reopened. Deleted plugins were located in:
  "C:\Program Files\Mozilla Firefox\searchplugins".
Product version is:
  "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5"

Comment 97

[Mike Connor [:mconnor]]

Clearing the app folder's searchplugins has nothing to do with this patch or the scope of this bug.

Comment 98

[rowlands]

Forgive me, but I disagree. If not, why are all the bugs regarding the installer/search plguin interactions (e.g. 263148, "Installation update installs standard search plugins again") marked as duplicates of this bug?

Comment 99

[Mike Connor [:mconnor]]

Simple.  The expected "fix" for those bugs was to make searchplugins a profile item.  

We didn't make all searchplugins profile items, and the reason we clear the app folder was for an unrelated reason (we established a naming convention for searchplugins across locales, and needed to avoid having duplicates when installing over (i.e. google.src (1.0) and google-de.src (1.5) would have both existed.  That was another bug, addressed much later than this.

Comment 100

[rowlands]

Understood, but still, the 1.5 installer silently destroyed my custom content, so I claim there's a bug that deserves to get fixed.

If the installer had showed any sign of remorse, I wouldn't be complaining right now. Something simple would have been OK, like backing up any search plugin that was not installed by default by any Firefox version.

Best would have been to move such plugins into my profile directory, update them to the new naming conventions, and resolve any naming conflicts. I get that that is harder than it sounds, which is why all I'm really asking for is to not delete my stuff.

Comment 101

[Jose Sa]

(In reply to comment #99)
> Simple.  The expected "fix" for those bugs was to make searchplugins a profile
> item.  
> 
> We didn't make all searchplugins profile items, and the reason we clear the app
> folder was for an unrelated reason (we established a naming convention for
> searchplugins across locales, and needed to avoid having duplicates when
> installing over (i.e. google.src (1.0) and google-de.src (1.5) would have both
> existed.  That was another bug, addressed much later than this.
> 

When will search plugins be treated as profile items?

If they are not yet (as it seems on 1.5 intaller) then there is still an unexpected behaviour.

At least it should be warned to the user that the folder will be overwritten.
If this were to be mentioned on http://www.mozilla.com/firefox/releases/1.5.html then I could have made backups. 

I believe that the Resolve Fixed is inappropriate since it resolves only part of the bug. The bug should remain open until all variations/implications are fixed.

Comment 102

[cor]

v2.0.0.11 = still happening!

Comment 103

[Michael Dougherty]

(In reply to comment #101)
> When will search plugins be treated as profile items?

This is still not the case in 3.05 or 3.1b2. Non-administrative users have no way of modifying, e.g. the Google search plugin for their own profile.

Comment 104

[Benjamin Smedberg]

Sure they do, the search engine manager allows you to install a different Google plugin if you wish, and/or disable the one that ships by default.

Comment 105

[:Gavin Sharp [email: [e-mail]]]

You can hide the default one, and install an alternative, but the alternative can't have the same name, due to bug 353056.

Comment 106

[cin.ya]

hallo,
to me it's not only important to search the directory for whatever I want to search it but also that the display changes. At the moment I can only display name, email-address or phone numbers, but I cannot chose other entries of the database. For me f.e. it would be important to display places where people live at the moment. 
ciao, cin.ya

Comment 107

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Cin, your comment has nothing to do with this bug report. Installed search engines can only list entries returned by the search engine hoster itself. It depends on their implementation for which items the search is run. Please check with your provider first or start a discussion on http://support.mozilla.com.