Closed Bug 137026 Opened 18 years ago Closed 10 years ago
[RFE] provide keyword support in search plugins
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.
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.
>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.
This is a demonstration plug-in, that would use regular Google for regular searching and I'm Feeling Lucky when used by Internet Keywords.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: samir_bugzilla → nobody
QA Contact: claudius → search
Target Milestone: Future → ---
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
Status: NEW → UNCONFIRMED
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
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.