Support for deep integrations, e.g. OpenSearch #421

manastungare · 2016-01-29T00:46:33Z

Listing deep integration endpoints in the manifest could allow user-agents to offer customized UI for specific actions. E.g. OpenSearch defines a URL syntax for search results based on query terms provided by the user.

Instead of requiring individual <meta> tags for all these, a single manifest could house all such endpoints.

Strawman format:

"endpoints": [{
  "type": "search",
  "label": "Search the Web",
  "url": "http://example.com/search?q={query}"
}, {
  "type": "search",
  "label": "Search Videos",
  "url": "http://example.com/search?corpus=videos&url={query}"
}]

The text was updated successfully, but these errors were encountered:

marcoscaceres · 2016-01-29T00:50:54Z

Do any browsers currently provide special/customized UI for the meta tag equiv.? I'm not familiar with this OpenSearch stuff.

manastungare · 2016-01-29T00:52:39Z

Chromium (and Chrome) let you tab to search, and rely on OpenSearch to discover the URL to do this.

https://www.chromium.org/tab-to-search

Among the many features Chromium's Omnibox offers is the ability to search a site without navigating to the sites homepage. Once Chromium has determined it can search a site, any time the user types the URL of the site into the Omnibox the user is offered the ability to search the site. Once the user presses tab, then types in a string and presses the enter, the site is searched and the results shown to the user. It's important to note the search is done by the site itself, not Google or Chromium.

Chromium provides two heuristics that automatically add a site to the list of searchable sites. The following describes these heuristics:

On your site's homepage provide a link to an OpenSearch description document. The link to the OSDD is placed in the head of the html file. For example:

<head>
 <link type="application/opensearchdescription+xml" rel="search"
       href="url_of_osdd_file"/>
</head>

The important part of this document is the URL used to search your site. The following is an example that contains the bare minimum needed, see the OpenSearch description document specification for the list of values you can specify.

<?xml version="1.0"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
  <ShortName>Search My Site</ShortName>
  <Description>Search My Site</Description>
  <Url type="text/html" method="get" template="http://my_site/{searchTerms}"/>
</OpenSearchDescription>

When the user presses enter in the Omnibox the string {searchTerms} in the url is replaced with the string the user typed.

marcoscaceres · 2016-01-29T01:05:18Z

I can't seem to get it to work in Chrome :( I tried going to Vimeo and typing vimeo in the omnibox, but it offers me no tab completion? can you help me get it working?

manastungare · 2016-01-29T01:17:40Z

This seems to work for me:

Navigate once to vimeo.com
In a new tab**, type "vimeo", then press tab.
Chrome may auto-complete to "vimeo.com".
Press tab once more.
The omnibox placeholder hint should change to “Search Vimeo”.
Type your query into the omnibox, press enter.

** Not strictly required, but seeks to illustrate that the user agent doesn't need the site to be active to show the tab-to-search UI.

marcoscaceres · 2016-01-29T07:06:24Z

Argh! 😞 for me pressing tab just seems to move down the list of options in the omnibox (trying on both Chrome stable and Chrome Canary on Mac).

Ok, but let's assume that it works. I need to check what Mozilla's plans are with regards to the OpenSearch stuff and if we plan to support it (i.e., the link@rel=search behavior) - as well as what the plans are for other implementers.

More of a concern for me is that this feature would put a requirement for the manifest to be downloaded on page load (possibly with a degree of priority, as presumably you want to make the search for a site available as early as possible - which link@rel=search already provides). Currently, loading the manifest early, or at all, is not a requirement because the manifest is used solely at install time and thus only needs to be lazily loaded when needed.

benfrancis · 2016-01-29T12:12:29Z

I think Firefox has supported OpenSearch link relations for years, but not with the same behaviour. I'm not sure what the current UI in desktop Firefox is though (if any) and it may currently be broken in Firefox for Android due to a bug... https://bugzilla.mozilla.org/show_bug.cgi?id=1225842

FWIW it could feasibly make sense to put OpenSearch metadata in the manifest given it tends to apply to a whole website, not just a single page. But as I understand it OpenSearch is already described by an XML description document linked from a rel=search link relation, not individual meta tags in the page?

manastungare · 2016-01-29T18:03:18Z

More of a concern for me is that this feature would put a requirement for the manifest to be downloaded on page load (possibly with a degree of priority, as presumably you want to make the search for a site available as early as possible

That would be an optimization over the status quo, but likely not a requirement. Any user interaction with the omnibox (or other search-specific UI) would happen after the page has loaded. The chief advantage of this is that on subsequent visits, the user agent will already have cached the manifest & OpenSearch URL.

Currently, loading the manifest early, or at all, is not a requirement because the manifest is used solely at install time and thus only needs to be lazily loaded when needed.

Agreed. Depends on how we define “install”. If we expand the definition to include “installing” a search provider, then this will need to happen at page load time (async, of course.)

The primary advantage will be consolidating all these individual resource definition XML files into a single coherent standard. There is no reason OpenSearch needs to stay a separate downloadable XML file if there’s already a manifest with a larger purpose being downloaded.

marcoscaceres · 2016-04-14T04:36:07Z

Marking as V2 feature. We will need to lobby the browser vendors to get behind this. However, I would like us to wait until after V1 has shipped as this is not high priority for anyone right now.

marcoscaceres · 2019-04-18T05:37:58Z

Closing as there hasn't been any interest expressed in this by implementers in the last few years.

Malvoz · 2019-06-27T22:48:17Z

@marcoscaceres

Seeing as all major browsers have implemented OpenSearch, and actively maintain them from what I can tell through responses in bug reports, I'm curious if that still holds true.

Because most browser do have a "tab-to-search"-feature, they must think it's something useful, however undoubtedly a lot of websites do not implement their own search functionality and so inspired by this article, I have proposed OpenSearch to allow for developers to utilize the users preferred search engine to perform searches instead of directly on-site. But I think this is a better place to raise my interest for the proposed feature.

As an aside (and perhaps I'll need to take this up with implementors directly), as the proposed feature builds on the ability that websites can use cross-origin URL templates, I can on a personal blog for example, let Google handle searches like so: <Url method="get" type="text/html" template="https://www.google.com/search?q=site:example.com+{searchTerms}"/>

Is it reasonable to worry that an attacker might inject an OpenSearch Description to instead reference an end-point of malicious intent? If this was implemented then the Manifest spec could perhaps restrict URL end-points to same-origin, or however you'd approach it (CSP?).

marcoscaceres · 2019-07-31T08:53:31Z

@Malvoz, sorry, I was not clear... we've not seen any interest in enabling OpenSearch via web manifest - that's not to say there is no interest in OpenSearch. Sorry for the confusion.

As an aside (and perhaps I'll need to take this up with implementors directly),

I would be really supportive of this - and I think you make a compelling case. I'm not sure who to ping at Mozilla about this. However, I'd encourage you to propose this to the WICG and cc me there. If you know of implementers you could pitch this idea too, that would be really helpful.

marcoscaceres added the Feature Request label Jan 29, 2016

marcoscaceres added this to the Level 2 milestone Apr 14, 2016

marcoscaceres closed this as completed Apr 18, 2019

Malvoz mentioned this issue Jun 25, 2019

Allow opensearch to use current browser search engine dewitt/opensearch#6

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for deep integrations, e.g. OpenSearch #421

Support for deep integrations, e.g. OpenSearch #421

manastungare commented Jan 29, 2016

marcoscaceres commented Jan 29, 2016

manastungare commented Jan 29, 2016

marcoscaceres commented Jan 29, 2016

manastungare commented Jan 29, 2016

marcoscaceres commented Jan 29, 2016

benfrancis commented Jan 29, 2016

manastungare commented Jan 29, 2016

marcoscaceres commented Apr 14, 2016

marcoscaceres commented Apr 18, 2019

Malvoz commented Jun 27, 2019 •

edited

Loading

marcoscaceres commented Jul 31, 2019

Support for deep integrations, e.g. OpenSearch #421

Support for deep integrations, e.g. OpenSearch #421

Comments

manastungare commented Jan 29, 2016

marcoscaceres commented Jan 29, 2016

manastungare commented Jan 29, 2016

marcoscaceres commented Jan 29, 2016

manastungare commented Jan 29, 2016

marcoscaceres commented Jan 29, 2016

benfrancis commented Jan 29, 2016

manastungare commented Jan 29, 2016

marcoscaceres commented Apr 14, 2016

marcoscaceres commented Apr 18, 2019

Malvoz commented Jun 27, 2019 • edited Loading

marcoscaceres commented Jul 31, 2019

Malvoz commented Jun 27, 2019 •

edited

Loading