Closed
Bug 86483
Opened 23 years ago
Closed 23 years ago
Add a drop down list of search engines to the basic search tab
Categories
(SeaMonkey :: Search, defect, P1)
SeaMonkey
Search
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: samir_bugzilla, Assigned: samir_bugzilla)
Details
(Whiteboard: Fix in hand; have r, sr; need a (mail sent to drivers))
Attachments
(3 files)
15.25 KB,
patch
|
Details | Diff | Splinter Review | |
13.80 KB,
patch
|
Details | Diff | Splinter Review | |
26.84 KB,
patch
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
Transferring nsbeta1+, milestone, and priority decorations from bugscape 4831.
Assignee | ||
Comment 2•23 years ago
|
||
Assignee | ||
Comment 3•23 years ago
|
||
matt, please r. alecf, please sr. Thanks.
Whiteboard: Fix in hand; need r, sr, a
Comment 4•23 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•23 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•23 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•23 years ago
|
||
Assignee | ||
Comment 8•23 years ago
|
||
Assignee | ||
Comment 9•23 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•23 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•23 years ago
|
||
r=matt
Updated•23 years ago
|
Whiteboard: Fix in hand; need r, sr, a → Fix in hand; have r,sr, need a
Assignee | ||
Updated•23 years ago
|
Whiteboard: Fix in hand; have r,sr, need a → Fix in hand; have r, sr; need a (mail sent to drivers)
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Assignee | ||
Comment 12•23 years ago
|
||
Checked into trunk.
Assignee | ||
Comment 13•23 years ago
|
||
Checked in on branch as well.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 14•22 years ago
|
||
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
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•