Open Bug 386591 Opened 17 years ago Updated 3 years ago

Support "result URLs" for search suggestion results (OpenSearch)

Categories

(Firefox :: Search, enhancement, P5)

Product:
Firefox
Component:
Search
Type:
enhancement

Tracking

()

People

(Reporter: syryos, Unassigned)

References

(
URL
)

Details

(Whiteboard: [fxsearch]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

See [1]

Currently, Firefox 2.x does not support the third and fourth parameter of the JSON response of suggesting search plugins (see [2] section "query URL" .

However, I am developing a search assistant in conformity to opensearch standard which need to send a URLs for the items it suggests (JSON 4th parameter). But the Firefox 2.x does ignore it currently.

I hereby ask for a swift implementation of the (3rd and) 4th parameter handling in Firefox.

[1] http://developer.mozilla.org/en/docs/Supporting_search_suggestions_in_search_plugins
"query URL:

This optional element is an array of alternate URLs for each of the suggestions in the completion list. For example, if you want to offer a map link instead of just a search result page for a given suggestion, you can return an URL to a map in this array. 

If you don't specify a query URL, the default query is used based on the search described by the <Url> element in the search plugin's XML description. 

>>>> Query URLs are not supported in Firefox 2, and are ignored." <<<<<

[2] http://www.opensearch.org/Specifications/OpenSearch/Extensions/Suggestions/1.0


Reproducible: Always
changed to blocking Firefox 3
Component: General → Search
Flags: blocking-firefox3?
Version: unspecified → 2.0 Branch
If you're volunteering to help fixing this, you should talk to Gavin, probably.
QA Contact: general → search
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Summary: Support request URLs of suggesting search plugins in conformity w/ opensearch standard → Support "result URLs" for search suggestion results (OpenSearch)
Version: 2.0 Branch → Trunk
(In reply to comment #2)
> If you're volunteering to help fixing this, you should talk to Gavin, probably.
>
I send an mail - no answer yet.


(In reply to comment #2)
> If you're volunteering to help fixing this, you should talk to Gavin, probably.
>
I sent an mail - no answer yet.


(In reply to comment #4)
> I sent an mail - no answer yet.

Sorry about that, your message got lost in my inbox :(. I think the best way to implement this functionality would be to provide a way for the nsIAutocompleteSearch (the search suggest component) to return extra meta data (the URL to load) to the nsIAutocompleteInput (the search bar) when onTextEntered is called. This solution would require modifying the autocomplete APIs, though it's possible we could find a hacky workaround specifically for the search suggest case. If you're interested in trying to fix this I'd be glad to help.
Nice to have, but not going to block.
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [wanted-firefox3]
(In reply to comment #5)
> implement this functionality would be to provide a way for the ... APIs, though it's possible we could find a hacky workaround specifically for the search suggest case. If you're interested in trying to fix this I'd be glad to help.

Sorry, I'm not a Firefox developer, I am developer of a "collaborative suggesting search engine" (to be exact: ... search assistant), thus, I only can offer to test this feature once someone else has added this to Firefox software.

again asking
Flags: blocking-firefox3-
Blocking Firefox 3

Reason:

This optional 4th parameter _is_ part of the opensearch standard. Why should Firefox ignore this standard ?


See http://www.opensearch.org/Specifications/OpenSearch/Extensions/Suggestions/1.0#Query_URLs

I urgently need this feature (4th parameter = request URL) urgentl (Query URLs - a list of URLs that should be used by the search client to request the suggested search term at the corresponding position in the completions lists. The URLs might be different for each of the suggestion.)
Flags: blocking-firefox3?
The drivers have already decided that it is not blocking firefox 3 though they would accept the feature if the work was done in time.
Flags: blocking-firefox3?
(In reply to comment #10)
> The drivers have already decided that it is not blocking firefox 3 though they
> would accept the feature if the work was done in time.
> 

Thanks for swift reply. I hope that someone is really implementing that missing 4th parameter, the sooner the better. You can contact me if testing with my special application (a suggesting search assistant, not a search engine) is needed.
It's my expressed wish that this parameter (defined in the OpenSearch standard) gets implemented in the Firefox 3.x release to make Firefox really compliant to that OpenSearch standard. Currently, it is not.
The http://www.opensearch.org standard suggests the optional use of the fourth parameter (4th parameter = request URL).

This allows a search engine or search assistant which has sent suggestions to the browser to define _different_ target urls: when a user selects an item from the list of suggestions, the next click can go to a dedicated target url (not necessarily the suggesting search engine).

I ask for a full implementation of the opensearch standard in the next Firefox version incl. 
http://www.opensearch.org/Specifications/OpenSearch/Extensions/Suggestions/1.0#Query_URLs

This feature will be needed for new search engines (agents, assistants) like Wikia or new Google appliances, which could sent prepared target urls which then can be directly jumped to (i.e. when user clicks onto an entry in the suggestion list, the prepared target is directly jumped to.)

Please can someone take over and implement this in Firefox 3.x ?
Flags: blocking-firefox3?
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]
No, again.  You've been told this before, and asking again won't change our minds.  I helped design and implement the feature, and I explicitly left this optional because there isn't a clear win or UI for it in Firefox.  The reaason this feature exists is for much richer implementations than we've currently done, its pretty silly to insist that this is a standards support bug.  Sometimes things are optional because they might not always be the right thing to do.
Flags: blocking-firefox3? → blocking-firefox3-
@ Mike,

I understood your comment. But your are not understanding me.

I am developing a search assistant, which differs from a search engine.
Please allow me to give you an example.

User queries (partial or full string "searchitem" in the search plugin input) are sent - as the user types - from Firefox client to the Searchassistant server like

    http://www.searchassistant.org/?q=<partial_or_full_searchitem>

    Example: user has typed "klm" (to make it easy, I use a full string as example)

(Thus after having added the search plugin via the add-search-plugin mechanisms)

Firefox fires

    http://www.searchassistant.org/?q=klm (example)

    The searchassistant server's JSON response is the following
    (here, a single line result is shown for simplicity)

    ["klm",["klm > KLM Airways"],[""],["http://www.klm.com/travel/nl_en/"]]


That's the point. The assistants does not get the query item back when the user selects that (here: single) line, but offers the a fully specified url as fourth parameter (here: address of KLM )
Thus, "klm" is NOT passed back to the search assistant server to invoke a kind of "I'm feeling lucky" search, because that result is already sent to the client.

I am very sorry, that you apparently did not understand my previous postings in that Mozilla bugzilla.

I do need the feature for my next research disclosure and hope to have convinced you. If I can help implementing or testing, please let me know.

Perhaps you can think over it and come to a different conclusion; I'll help you as much as I can. The implementation in Firefox looks very very simple to me, but my view may be very naive.

(In reply to comment #15)
> I am very sorry, that you apparently did not understand my previous postings in
> that Mozilla bugzilla.

I think you're the one not understanding. Both Mike and I are familiar with the "result URLs" feature and know what it is used for. But we're not going to block Firefox 3 for a feature that is of little general use. So far you're the only person that's requested it; that doesn't mean we shouldn't implement it, but there are more pressing things to fix before Firefox 3 is released.

> I do need the feature for my next research disclosure and hope to have
> convinced you.

You can work around the lack of this feature by having your engine description file's text/html URI forward to the URI you sent in the suggest URI's JSON results. It requires more work on the server side, sure, but it's certainly not impossible to achieve the same effect with a server-side only approach.

> If I can help implementing or testing, please let me know.

I've already explained how I think this needs to be implemented, in comment 5. If someone steps up to do that work, I can help answer any questions and review the code.
(In reply to comment #5)
> (In reply to comment #4)
> > I sent an mail - no answer yet.
> 
> Sorry about that, your message got lost in my inbox :(. I think the best way to
> implement this functionality would be to provide a way for the
> nsIAutocompleteSearch (the search suggest component) to return extra meta data
> (the URL to load) to the nsIAutocompleteInput (the search bar) when
> onTextEntered is called. This solution would require modifying the autocomplete
> APIs, though it's possible we could find a hacky workaround specifically for
> the search suggest case. If you're interested in trying to fix this I'd be glad
> to help.
> 

What about creating an own autocomplete for the searchbar? The addressbar also got its own and furthermore, not all autocompletes need a hidden value different from the text of selected suggestion. (Modifying nsSearchSuggestions.js seems to be easy, but the rest...)
Not sure what you mean by "own autocomplete". You mean a new autocomplete binding that uses the existing nsIAutoCompleteResult members to pass the data, similar to how the "rich autocomplete" binding works? That could probably work, though it would be nice to change the APIs such that we could clean up the "rich autocomplete" binding too, instead of just duplicating it's hackiness.
Gavin, have you reconsider implementing this feature? I understand your work-around using a server redirect but that assumes that the server knows the target url. 

Unfortunately, this doesn't work very well since it depends on the search term (a string) to figure out where to redirect the user. 

Consider the typical "jaguar" search example - this might suggest two terms, jaguar the animal, and jaguar the car company. Whatever the user clicks on, this will still result in a search for "jaguar" and is impossible for the server to know which one the user clicked on unless there is a disambiguating string passed on from the suggest control.

Since there is no information passed on to the text/html search page of what the user selected using the suggest drop-down, the suggested (pun not intended) work-around will not work for a really large portion of pages.
(In reply to comment #19)
> Gavin, have you reconsider implementing this feature? I understand your
> work-around using a server redirect but that assumes that the server knows the
> target url. 

There isn't really anything to reconsider - I still don't have time at the moment to implement this feature because I'm working on other things. I would be very happy to guide someone else through doing the work. Comment 5 and 18 mention possible implementation strategies.

> Consider the typical "jaguar" search example - this might suggest two terms,
> jaguar the animal, and jaguar the car company. Whatever the user clicks on,
> this will still result in a search for "jaguar"

That doesn't sound like a very plausible scenario. How is the user supposed to distinguish between the car and the animal if all they see are two identical suggestions? The suggestions need to be distinguishable by the user for them to be useful. Given the current implementation, if they are distinguishable by the user, they are distinguishable by the server receiving the queries too.
I understand regarding the ability to implement this now - thanks.

Regarding the other question, the spec also allows you to return a description for each item that would help you disambiguate right in the suggest box. 

Right now, I also include an id in the suggested string so that I can redirect appropriately (but it's not a proper UI since the user can see the id).
(In reply to comment #20)
> Given the current implementation, if they are distinguishable by the
> user, they are distinguishable by the server receiving the queries too.
"Jaguar" --> as you mentioned, can have two or more results. This means two o rmore different(!) "result URLs". These result URLs - when using the result URL parameter - are not pointing back to the search engine with the argument "jaguar" and a additional indication - but should directly point to the two or more different target servers (Jaguar company server; Jaguar animal in Wikipedia server and so on).
Yes, again, I know how the result URLs feature works - you don't need to keep explaining it :)

I'm just pointing out that that alone won't solve Michael's problem of wanting to return multiple identical suggestions without additional changes that lets the be distinguished by the user (such as exposing the descriptions he refers to in comment 21).
I thought I'd just point out that <a href="http://blogs.msdn.com/ie/archive/2008/09/18/hello-world-getting-started-with-ie8-visual-search.aspx
">Internet Explorer 8</a> will be shipping with <a href="http://www.opensearch.org/Specifications/OpenSearch/1.1/Draft_3">OpenSearch 1.1 support</a>.
(In reply to comment #24)
> I thought I'd just point out that Internet Explorer 8 will be shipping with OpenSearch 1.1 support 

Thank you! It is indeed very interesting.

Citing that page http://blogs.msdn.com/ie/archive/2008/09/18/hello-world-getting-started-with-ie8-visual-search.aspx 

"There are [three] important pieces we define in this file:

* A Results Page URL whose MIME type is text/html, where the user will land after a search—here, results.aspx. The “{searchTerms}” part will automatically be replaced by IE with the user’s search terms. In this sample, I assume your website has an integrated search engine. If it doesn’t, and unless it’s an intranet website, you may replace that URL with the following one instead, which will search your domain using live.com:
      http://search.live.com/results.aspx?q=site:www.example.com+{searchTerms} "
(In reply to comment #24)
> I thought I'd just point out that Internet Explorer 8 will be shipping with
> OpenSearch 1.1 support

The more relevant question is whether they are supporting result URLs specifically. "OpenSearch1.1" support is kind of vague, and doesn't necessarily mean full support for all features defined in that spec.

(In reply to comment #25)
> Citing that page

I'm not sure why you bothered citing that, since it describes the part of OpenSearch that Firefox and IE already both implement.
(In reply to comment #26)
> I'm not sure why you bothered citing that, since it describes the part of
> OpenSearch that Firefox and IE already both implement.

No, they do _not_, as that parameter means that each URL for each single suggestion (among the plurality of suggestions to a certain {searchTerm}) _can_ point to an arbitray URL, _different_ servers, not necessarily the search-engine server delivering the JSON reply of suggestions.
(In reply to comment #27)
> No, they do _not_, as that parameter means that each URL for each single
> suggestion (among the plurality of suggestions to a certain {searchTerm}) _can_
> point to an arbitray URL, _different_ servers, not necessarily the
> search-engine server delivering the JSON reply of suggestions.

You're misinterpreting the text on that page. The "Results Page URL" they refer to is just a normal <Url type="text/html" template="...">, as you can see in the example they provide. They're not talking about result-specific URLs for suggestions (and in fact they don't mention the suggestion JSON format at all).
I too would be interested in this feature. It is correct that the third (the description field) is also ignored?
I spent the last four hours trying to find a not-existing bug in my JSON data, only to find that the latest Firefox doesn't properly support this feature. Argh! Usually it's the other way around. Right now everyone is impressed with what IE8 delivers in that respect.

I have never looked at the source code - maybe I should. What's explained in Comment#5 doesn't sound too complicated ...
(In reply to comment #20)
> (In reply to comment #19)
> > Consider the typical "jaguar" search example - this might suggest two terms,
> > jaguar the animal, and jaguar the car company. Whatever the user clicks on,
> > this will still result in a search for "jaguar"
> 
> That doesn't sound like a very plausible scenario. How is the user supposed to
> distinguish between the car and the animal if all they see are two identical
> suggestions? The suggestions need to be distinguishable by the user for them > to be useful.

There's other examples that would benefit from implementing this feature properly. I have just implemented an employees search on our company intranet. With 1000+ employees, quite a few of them have the same first or last names. So the text response to any input is a list of the full name of matched employees. The URL returned for one of those matches would bring you to an employee detail site, whereas the current state 'just' calls the main search form with the full name, delivering only one result.
I'd also love to see this feature implemented - and the descriptions value as well, just like IE8.  I now count 8 people requesting this!

I've got a partial workaround for my site search by adding a tab character to the end of the suggested search term.  The tab is invisible to the user, so no visible id is required (I tried a zero width space but IE8 didn't like it).  If the search page sees the tab it knows the search must have come from the search suggestion and can automatically redirect users to first search result.
I'm a developer of a search service, and I'd also like to see this feature implemented to be able to provide the same service archicture for FF as we do for IE8.
Priority: -- → P5
Whiteboard: [fxsearch]
Rank: 59
Severity: normal → N/A
Rank: 59
You need to log in before you can comment on or make changes to this bug.