Last Comment Bug 386591 - Support "result URLs" for search suggestion results (OpenSearch)
: Support "result URLs" for search suggestion results (OpenSearch)
Status: NEW
[fxsearch]
:
Product: Firefox
Classification: Client Software
Component: Search (show other bugs)
: Trunk
: All All
: P5 enhancement 59 with 17 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://developer.mozilla.org/en/docs/...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-02 08:24 PDT by syryos
Modified: 2015-09-23 09:05 PDT (History)
19 users (show)
mconnor: blocking‑firefox3-
reed: wanted‑firefox3+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description syryos 2007-07-02 08:24:49 PDT
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
Comment 1 syryos 2007-07-03 01:41:25 PDT
changed to blocking Firefox 3
Comment 2 Nickolay_Ponomarev 2007-07-03 08:06:44 PDT
If you're volunteering to help fixing this, you should talk to Gavin, probably.
Comment 3 syryos 2007-07-10 15:55:01 PDT
(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.

Comment 4 syryos 2007-07-10 15:55:34 PDT
(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.

Comment 5 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-07-11 08:28:14 PDT
(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.
Comment 6 Mike Connor [:mconnor] 2007-07-23 11:40:31 PDT
Nice to have, but not going to block.
Comment 7 syryos 2007-07-30 06:02:28 PDT
(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.
Comment 8 syryos 2007-08-06 03:29:21 PDT
again asking
Comment 9 syryos 2007-09-01 10:17:18 PDT
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.)
Comment 10 Dave Townsend [:mossop] 2007-09-01 10:21:04 PDT
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.
Comment 11 syryos 2007-09-01 13:05:55 PDT
(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.
Comment 12 syryos 2007-11-20 00:36:54 PST
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.
Comment 13 syryos 2008-01-08 16:45:17 PST
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 ?
Comment 14 Mike Connor [:mconnor] 2008-02-04 22:53:34 PST
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.
Comment 15 syryos 2008-02-12 18:42:08 PST
@ 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.
Comment 16 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-02-13 08:01:08 PST
(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.
Comment 17 Sebastian Hengst [:aryx][:archaeopteryx] 2008-08-10 15:47:23 PDT
(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...)
Comment 18 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-08-18 00:55:27 PDT
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.
Comment 19 Michael Masouras 2008-10-03 12:16:59 PDT
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.
Comment 20 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-10-03 16:34:56 PDT
(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.
Comment 21 Michael Masouras 2008-10-03 19:10:38 PDT
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).
Comment 22 syryos 2008-10-04 00:14:56 PDT
(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).
Comment 23 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-10-04 00:21:52 PDT
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).
Comment 24 Robbie Paplin 2008-10-14 22:50:52 PDT
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>.
Comment 25 syryos 2008-10-14 23:09:28 PDT
(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} "
Comment 26 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-10-16 12:17:27 PDT
(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.
Comment 27 syryos 2008-10-16 13:54:45 PDT
(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.
Comment 28 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-10-17 11:05:35 PDT
(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).
Comment 29 Peksa 2009-06-30 07:51:13 PDT
I too would be interested in this feature. It is correct that the third (the description field) is also ignored?
Comment 30 Michael Ehrt 2010-01-13 09:37:18 PST
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 ...
Comment 31 Michael Ehrt 2010-01-13 23:48:09 PST
(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.
Comment 32 Daniel Lewis 2010-01-20 15:41:52 PST
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.
Comment 33 Johannes Lietz 2010-04-21 06:03:59 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.