137026 - [RFE] provide keyword support in search plugins

Status: RESOLVED EXPIRED

(SeaMonkey :: Search, enhancement)

Description

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Anybody should be able to provide an Internet Keywords server.  Giving the
business to AOL/TW and only AOL/TW is a cause of concern for many. (see bug 76547)

Now, we don't want to have to manage a whole set of Internet Keywords plugins,
so the elegant solution is just to use the Default Search Engine, and append
this suffix.

For background, search already appends &sourceid=mozilla-search, so we're not
worried about an unexpected key/value pair in the URL.

People who wish to have the current behavior simply select Netscape as their
default search engine, and the guys at netscape.com put a couple lines of code
in the search handler to redirect to the keywords server when they see this
sourceid, and everything chugs right along.  They can do that code today with no
noticeable effects and when this feature lands both methods work.

Many people expect the default search engine to kick in already when hitting
enter in the URL bar (it's even labeled as such - see bug 53171) so if their
search engine of choice comes up noone will be surprised.  If their search
engine chooses not to handle internet keywords they will still see the search
results.  That takes care of bug 53171.

I have no problem with leaving the default search engine as Netscape, so out of
box, Internet Keywords will work just like they do today, but at least there's
freedom of choice.

Comment 1

[Ben Bucksch (:BenB)]

I don't think that this is a good idea, because it makes certain assumptions
about the server.

1. Mozilla-defined search strings
The search strings Mozilla sends should be configurable, not have hardcoded
values like you propose.
For example, I currently use Google's "I'm feeling lucky" as Keyword provider.
The search string I use is different from what would be produced with your
proposal. It would be at Google's discretion to support that "Mozilla extention"
to access I'm feeling lucky or not to do so.

2. Search and IK linked (less severe)
Currently, I can select Google as IK provider and at the same time Altavista as
Search provider. I can't do that with this proposal.

Comment 2

[Bill McGonigle (not currently reading bugmail; please contact directly)]

>1. Mozilla-defined search strings

You're right, I hosed this up, based on a bad assumption about the way the
Google plug-in was doing things... I've read all the plugins now.  Here's a
better proposal:

A flexible way to do this would be to support keywords in the search plugin. 
For instance, a

keyword = "foo"

line in the <search> section, then support for a keyword input type:

<input name="bar" keyword>

Would allow a keyword search utilizing a plug-in to postpend &bar=foo to the
query.  bar, for google might be sourceid and foo might be mozilla-keywords, but
it wouldn't have to be.  The only tricky part would be that the keyword <input>
field shoudln't be included if it's not a keyword search.

>2. Search and IK linked (less severe)
>Currently, I can select Google as IK provider and at the same time Altavista as
>Search provider. I can't do that with this proposal.

I don't mean to address the UI with this bug, per se.  If someone wants to have
a second popup selector for the IK server, that's fine with me.  Right now,
since Netscape is the only choice for the user, I'm trying to come up with a
backwards-compatible baby step that will take us in a more open direction.

Comment 3

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Attachment: Google plug-in with keyword support

This is a demonstration plug-in, that would use regular Google for regular
searching and I'm Feeling Lucky when used by Internet Keywords.

Comment 4

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Hmm, I never annotated how to parse this example, though it's pretty easy:

In the <search> tag, there is the tuple:

   keyword="I%27m+Feeling+Lucky"

and an <input> tag:

   <input name="btnI" keyword>

In the case of a keywords search, this would cause the string
&btnI=I%27m+Feeling+Lucky to be appened to the normal search query.  In a normal
search, it would be ignored.

Another possibility would be supporting:

    keyword=user

in the <search> tag.  This would make the system somewhat more flexible, so you
could have

<input name="mozilla-keyword-search" keyword>

to get &mozilla-keyword-search=some+user+data, but you'd probably want to skip
the normal <input ... user> tag if that case was triggered.

Comment 5

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 6

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420