Allow search plugins to have a "search page" URL for blank searches

RESOLVED FIXED in Firefox 2 beta1

Status

()

P3
enhancement
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: jconley, Assigned: Gavin)

Tracking

({fixed1.8.1})

2.0 Branch
Firefox 2 beta1
fixed1.8.1
Points:
---
Bug Flags:
blocking-firefox2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I often use keyword searches (currently keyword bookmarks) with and without the %s parameter substitution.

Would be nice if future keyword searching could use a different url for non-parameter requests vs those with a parameter request.

For example:
'bug' would use url 'http://bugzilla.mozilla.org'
'bug 317107' would use url 'https://bugzilla.mozilla.org/show_bug.cgi?id=%s'

'g' would use url 'http://www.google.com'
'g keyword' would use 'http://www.google.com/search?q=%s&hl=en'


Reproducible: Always
(Reporter)

Updated

13 years ago
Blocks: 317107
Version: unspecified → 1.5 Branch
(Reporter)

Comment 1

13 years ago
In the meantime I found a way to hack this in 1.5 using bookmark javascript:
javascript:(function(){document.location=('%s'!='\%\s'?'http://www.google.com/search?q=%s&hl=en':'http://www.google.com');})();

Comment 2

13 years ago
Related to bug 298697?
(Reporter)

Comment 3

13 years ago
No, not related. 298697 says %s is not replaced with empty string when no parameter is specified.
No longer blocks: 317107
Depends on: 317107
Assignee: nobody → gavin.sharp
OS: Windows XP → All
Hardware: PC → All
Summary: Allow keyword searches to have a parameter and non-parameter url → Allow keyword search to have a parameter and non-parameter url
Target Milestone: --- → Firefox 2 alpha2
Sherlock plugin description files can specify a "searchForm" attribute (http://mycroft.mozdev.org/deepdocs/searchtag.html#searchForm), I couldn't find an equivalent OpenSearch attribute but I'll look into it further. This attribute will be used when pressing enter in the search bar with no search terms. Plugins that don't specify an alternate searchForm will likely use just the host of the query URL (i.e. google.com for google.com/?q=foo). I'm still not how bookmark keywords and the search service will interact - I'm thinking that maybe what is now known as "bookmark keywords" will become "search engines" that appear in the management UI but not in the toolbar.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Version: 1.5.0.x Branch → 2.0 Branch
This is ripe for cutting right now.
Flags: blocking-firefox2+
Created attachment 219837 [details] [diff] [review]
add searchForms to existing plugins
Attachment #219837 - Flags: review?(mconnor)
Whiteboard: [patch-r+]
Whiteboard: [patch-r+] → [patch-r?]
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1
Comment on attachment 219837 [details] [diff] [review]
add searchForms to existing plugins

>   get searchForm() {
>-    // XXX OpenSearch has a searchForm attribute, should use it instead of this
>-    // ugly ugly hack
>+    if (this._searchForm)
>+      return this._searchForm;
>+    // XXX hack
>     return makeURI("http://" + makeURI(this._urls[0].template).host).spec;
>   },

can you add a more expansive comment explaining what we're doing here (going to the domain root for the searchplugin)
Attachment #219837 - Flags: review?(mconnor)
Attachment #219837 - Flags: review+
Attachment #219837 - Flags: approval-branch-1.8.1+
Whiteboard: [patch-r?] → [checkin needed]

Comment 8

13 years ago
>     return makeURI("http://" + makeURI(this._urls[0].template).host).spec;

Why always http?  Why not use the protocol specified along with the hostname?
(In reply to comment #8)
> >     return makeURI("http://" + makeURI(this._urls[0].template).host).spec;
> 
> Why always http?  Why not use the protocol specified along with the hostname?

No good reason, I'll make that change.
Created attachment 223862 [details] [diff] [review]
better patch

- Use Jesse's suggestion from comment 8
- Fix searchForm get as discussed on IRC
- make it return the searchForm when submitting a blank query, too
Attachment #219837 - Attachment is obsolete: true
(In reply to comment #10)
> - Use Jesse's suggestion from comment 8
> - Fix searchForm get as discussed on IRC
> - make it return the searchForm when submitting a blank query, too

Also: changed the parse* functions to sync with changes from bug 335472.
Checked in attachment 223862 [details] [diff] [review], branch and trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Hrm, I really didn't fix this bug as summarized - the plan was to have search plugins be the backend for keyword search, but that didn't happen. Bug 306221 covers the original intent of this bug, though, so I'm going to fully morph this one.
Summary: Allow keyword search to have a parameter and non-parameter url → Allow search plugins to have a "search page" URL for blank searches
*** Bug 322934 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.