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

VERIFIED FIXED in mozilla0.9.3

Status

SeaMonkey
Search
P1
normal
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Samir Gehani, Assigned: Samir Gehani)

Tracking

Trunk
mozilla0.9.3

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Fix in hand; have r, sr; need a (mail sent to drivers))

Attachments

(3 attachments)

(Assignee)

Description

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

Comment 1

17 years ago
Transferring nsbeta1+, milestone, and priority decorations from bugscape 4831.
Status: NEW → ASSIGNED
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla0.9.2
(Assignee)

Comment 2

17 years ago
Created attachment 39102 [details] [diff] [review]
Patch to add a drop down menu to choose an engine to search with in basic mode.
(Assignee)

Comment 3

17 years ago
matt, please r.
alecf, please sr.

Thanks.
Whiteboard: Fix in hand; need r, sr, a

Comment 4

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

Comment 5

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

Comment 6

17 years ago
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.
Whiteboard: Fix in hand; need r, sr, a → ETA for modified patch: 2001-06-20
(Assignee)

Comment 7

17 years ago
Created attachment 39427 [details] [diff] [review]
Patch with notion of version instead of mode (cvs diff -w -u6 since lots of whitespace changes)
(Assignee)

Comment 8

17 years ago
Created attachment 39428 [details] [diff] [review]
Patch with notion of version (same as above but just cvs diff -u6 showing my whitespace changes are actually OK).
(Assignee)

Comment 9

17 years ago
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.
Whiteboard: ETA for modified patch: 2001-06-20 → Fix in hand; need r, sr, a

Comment 10

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

17 years ago
r=matt

Updated

17 years ago
Whiteboard: Fix in hand; need r, sr, a → Fix in hand; have r,sr, need a
(Assignee)

Updated

17 years ago
Whiteboard: Fix in hand; have r,sr, need a → Fix in hand; have r, sr; need a (mail sent to drivers)

Updated

17 years ago
Keywords: nsBranch

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3
(Assignee)

Comment 12

17 years ago
Checked into trunk.
(Assignee)

Comment 13

17 years ago
Checked in on branch as well.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
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.]
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.