86483 - Add a drop down list of search engines to the basic search tab

Status: VERIFIED FIXED

(SeaMonkey :: Search, defect, P1)

Description

[Samir Gehani]

Add a drop down list to the Basic (default tab) that is similar to the current
drop down in the advanced search tab.  The list of engines that appears in this
tab will only be those that are tagged as "basic" in the Sherlock plugin
describing the search engine.  This allows vendors based on Mozilla, e.g.,
Netscape, to only show engines they bless while still allowing Mozilla to
display all/any engines.  (The alternate method of tagging non-basic Sherlock
plugins as "advanced" and keeping basic engines untagged was considered but does
not allow browser vendors to restrict the list because this leads to the
unsdesrable effect that plugins from a previous installation may show up in the
basic search engine popup.)

Comment 1

[Samir Gehani]

Transferring nsbeta1+, milestone, and priority decorations from bugscape 4831.

Comment 2

[Samir Gehani]

Attachment: Patch to add a drop down menu to choose an engine to search with in basic mode.

Comment 3

[Samir Gehani]

matt, please r.
alecf, please sr.

Thanks.

Comment 4

[Alec Flett]

My one concern is that other search engine resource files out there might not
have mode = "basic" - for instance the ones that are linked to off of tinderbox
- they won't appear in the "basic" search engine list

what about the reverse, marking search engines as "advanced" and then /hiding/
the advanced ones - then Netscape can flag the search engines they care about as
"advanced"

Comment 5

[Samir Gehani]

Alec,
I thought about your idea which seemed to work well initially (tagging
mode="advanced" and hiding those).  My original report in this bug includes a
parenthetical that explains why we can't do that.  But I missed an important
point: basically if users upgrade from a previous version they will have old
untagged sherlock plugins lying around.  Tagging only the new ones that we
install gives us the ability to hide old ones from the basic drop down.  That
being said, I just thought of another problem: we don't have any versioning in
place for these plugins.  This means, if a user upgrades again they will see old
"basic" plugins lying around even if we don't ship with them.  So we solve the
problem of old ones lying around only one time.  Sigh.

I guess we could add versioning.  If mozilla doesn't want to use the versioning
feature we can always search for the same version.  Comments?

I am aware that these comments have not addressed your concern but it seems that
the desired behavior for mozilla may be divergent than what vendors -- like
Netscape -- would like to have.  Can anyone think of a smarter way to do this?  

Comment 6

[Samir Gehani]

After consulting with Alec, Todd, and, Matt we concluded that we are barking up
the wrong tree with the notion of mode.  What we really want is the notion of
version.  There will be a minimum permissible version set as a pref, say
"browser.search.basic.min_ver".  If a sherlock file does not contain a version
it'll be given a default (something reasonable like 1.0).  We will display all
sherlock plugins with version >= pref setting of minimum version.  

This will satisfy mozilla as well as commercial requirements:
1> No constraining of the mozilla basic list since we will have the minimum
version set to 0.0 or some such.
2> As we move forward vendors may choose to ship with a bumped up minimum version.

Comment 7

[Samir Gehani]

Attachment: Patch with notion of version instead of mode (cvs diff -w -u6 since lots of whitespace changes)

Comment 8

[Samir Gehani]

Attachment: Patch with notion of version (same as above but just cvs diff -u6 showing my whitespace changes are actually OK).

Comment 9

[Samir Gehani]

OK guys, hopefully this is it.  Note that we don't need to set the
browser.search.basic.min_ver pref in mozilla's all.js.  If the pref is missing,
the default minimum version is just assumed to be 0.0.  And if the version is
missing from the sherlock plugin's <SEARCH> tag then the default is assumed to
be 1.0.  So *all* engines show up in mozilla since 1.0 >= 0.0.

matt, please r.
alecf, please sr.

Thanks.

Comment 10

[Alec Flett]

ok, a few issues:
ugh. I was just going to say "don't use copyUnicharPref" but it looks like
nsPreferences doesn't support that. Argh. 

Anyway, I guess that will work just fine.

do you mind putting an entry in all.js though? It's good documentation until
this pref is documented, not to mention it's really kind of a policy of ours to
give a default value to all prefs.

thanks
sr=alecf on the code that's here, but I want the pref in all.js :)

Comment 11

[matt]

r=matt

Comment 12

[Samir Gehani]

Checked into trunk.

Comment 13

[Samir Gehani]

Checked in on branch as well.

Comment 14

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]