Intent to Deprecate and Remove: window.external.AddSearchProvider

[Evan Stade]

Primary eng (and PM) emails

od...@google.com, est...@chromium.org, pkas...@chromium.org

Summary

We plan to remove support for window.external.AddSearchProvider

Motivation

We think this feature doesn't get much usage and is largely redundant with <link rel="search">

Compatibility Risk

Chrome: Desktop Chrome supports this feature but mobile (both Android and iOS) does not

IE: This feature was supported in IE7-9 but deprecated in IE10+ and not present in Edge.

FF: the feature has existed in firefox since FF2 and is still supported in FF41.

Safari: no support

Alternative implementation suggestion for web developers

<link rel="search"> takes care of most use cases. In Chrome's current implementation, <link> will only work for toplevel pages (e.g. example.com but not example.com/faq). It also permits just one search engine per domain (AddSearchProvider allows multiple search engines for the same domain with user consent).

Usage information from UseCounter

This feature is not yet instrumented. I plan to add instrumentation shortly.

OWP launch tracking bug

http://crbug.com/542487

Entry on the feature dashboard

None right now. Does this change merit outreach?

Requesting approval to remove too?

Yes

-- Evan Stade

[TAMURA, Kent]

lgtm1

--

TAMURA Kent
Software Engineer, Google

[Anne van Kesteren]

On Tue, Oct 13, 2015 at 3:39 AM, Evan Stade <est...@chromium.org> wrote:
> Summary
> We plan to remove support for window.external.AddSearchProvider
>
> Motivation
> We think this feature doesn't get much usage and is largely redundant with
> <link rel="search">

File a bug against the HTML standard to get it removed there first?


--
https://annevankesteren.nl/

[Jochen Eisinger]

Could somebody summarize what has changed since the last time where Peter was opposed to removing this API?

[Evan Stade]

On Tue, Oct 13, 2015 at 12:05 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Could somebody summarize what has changed since the last time where Peter was opposed to removing this API?

It was agreed that we should measure usage and go through the formal removal process. This thread contains more info than the last:

1) concrete explanation of differences to <link>

2) overview of implementation status in other browsers

3) promise of instrumentation

There was also investigation that discovered a number of bugs (albeit fixable) which demonstrate the maintenance cost and risk of maintaining the API. Thus I believe this conversation can move forward and we can agree on a course of action pending the outcome of the usage metrics.

 

On Tue, Oct 13, 2015 at 8:10 AM Anne van Kesteren <ann...@annevk.nl> wrote:

File a bug against the HTML standard to get it removed there first?

Can someone with more standards experience than myself answer if this is typical? It seems like something that could be done in parallel.

[Rick Byers]

On Tue, Oct 13, 2015 at 11:33 AM, Evan Stade <est...@chromium.org> wrote:

On Tue, Oct 13, 2015 at 12:05 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Could somebody summarize what has changed since the last time where Peter was opposed to removing this API?

It was agreed that we should measure usage and go through the formal removal process. This thread contains more info than the last:

1) concrete explanation of differences to <link>

2) overview of implementation status in other browsers

3) promise of instrumentation

I'd personally prefer to have that number before making a decision on deprecation - we want to avoid spammy deprecation warnings. 

I just did a quick httparchive search and found this API used on ~516 of the top 200k websites, including Google.com (and each geo variant of it).  So perhaps the first step is at least understand the implication of the change on some of these sites.  Does the user experience degrade at all? For google.com in particular (or other similarly major websites), we should probably engage with the site owners first about removing their usage of the API.

There was also investigation that discovered a number of bugs (albeit fixable) which demonstrate the maintenance cost and risk of maintaining the API. Thus I believe this conversation can move forward and we can agree on a course of action pending the outcome of the usage metrics.

 

On Tue, Oct 13, 2015 at 8:10 AM Anne van Kesteren <ann...@annevk.nl> wrote:

File a bug against the HTML standard to get it removed there first?

Can someone with more standards experience than myself answer if this is typical? It seems like something that could be done in parallel.

I actually don't know myself what is typical for removal.  But if Anne thinks it's reasonable to start talking about removing it from the spec now, then I definitely think it's at least worth starting that discussion by filing a spec bug.

[PhistucK]

And what about external.IsSearchProviderInstalled(url)? Why bother keeping it?

Rick - I changed my default search engine in order to see if Google shows any message and it did not. I am not sure it is actually used in practice. Probably dead code.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Evan Stade]

On Tue, Oct 13, 2015 at 8:37 AM, Rick Byers <rby...@chromium.org> wrote:

On Tue, Oct 13, 2015 at 11:33 AM, Evan Stade <est...@chromium.org> wrote:

On Tue, Oct 13, 2015 at 12:05 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Could somebody summarize what has changed since the last time where Peter was opposed to removing this API?

It was agreed that we should measure usage and go through the formal removal process. This thread contains more info than the last:

1) concrete explanation of differences to <link>

2) overview of implementation status in other browsers

3) promise of instrumentation

I'd personally prefer to have that number before making a decision on deprecation - we want to avoid spammy deprecation warnings. 

I just did a quick httparchive search and found this API used on ~516 of the top 200k websites, including Google.com (and each geo variant of it).  So perhaps the first step is at least understand the implication of the change on some of these sites.  Does the user experience degrade at all? For google.com in particular (or other similarly major websites), we should probably engage with the site owners first about removing their usage of the API.

That data is a year old, and I expect the trend to be downwards: for example google.com doesn't appear to use it any more. Plus, a lot of those uses don't actually work, if I'm interpreting the columns correctly. If the page and URL don't share the same domain, Chrome will ignore it. This is even part of the WhatWG spec:

"""

The OpenSearch description document has to be on the same server as the script that calls this method.

"""

Then there are some sites like animup.net which don't work for various other reasons (like calling the API from an onclick on <option>, which doesn't work). There are a few examples from that doc which do work: http://izlesem.org/, http://gegenteil-von.com/ etc. and these appear to be replaceable with <link rel="search">.

I would like to instrument this feature with UseCounter, but that doesn't seem straightforward because of implementation details (it's a v8 extension, not part of core blink).

 

> And what about external.IsSearchProviderInstalled(url)? Why bother keeping it?

Good question, I was going to add a use counter there too. IE has deprecated it as well, but it seems less clear that it's unused.

[Jochen Eisinger]

As Rick, I'm fine with deprecating, but we should only decide on removal when we have the numbers.

I think we should also discuss how the UMA numbers should be interpreted, as a site that uses this API and depends on it might still only use it once per user.

So maybe measuring isSearchProviderInstalled() gives us better data?

[Evan Stade]

On Tue, Oct 13, 2015 at 10:09 AM, Jochen Eisinger <joc...@chromium.org> wrote:

As Rick, I'm fine with deprecating, but we should only decide on removal when we have the numbers.

I think we should also discuss how the UMA numbers should be interpreted, as a site that uses this API and depends on it might still only use it once per user.

The UMA counts I added allow us to see what % of users use the feature. That seems like a pretty good measure of usefulness. I don't know the threshold for "keep". 0.5%?

 

So maybe measuring isSearchProviderInstalled() gives us better data?

I have a CL out to measure both of these, but I don't think we can assume they're typically used together (even though that would be intuitive). For example, http://izlesem.org/ doesn't use IsSearchProviderInstalled, and IsSearchProviderInstalled is potentially used just to determine the default search engine (for promos and so forth). AddSearchProvider can't affect the default search engine, so it wouldn't be the next step if you were trying to convert users to use your engine as default.

[Rick Byers]

The API owners met and discussed this today.  Overall we're skeptical that usage of this API is low enough to enable deprecation/removal (given that we know there are some use cases enabled by this API which are not otherwise possible to solve).

The next step is probably collecting usage metrics for BOTH IsSearchProviderInstalled and AddSearchProvider - if they both fall below a low usage (eg. 0.03%) threshold then we can probably more seriously explore removal.

More responses inline.

On Tue, Oct 13, 2015 at 1:09 PM, Jochen Eisinger <joc...@chromium.org> wrote:

As Rick, I'm fine with deprecating, but we should only decide on removal when we have the numbers.

I think we should also discuss how the UMA numbers should be interpreted, as a site that uses this API and depends on it might still only use it once per user.

So maybe measuring isSearchProviderInstalled() gives us better data?

On Tue, Oct 13, 2015 at 6:38 PM Evan Stade <est...@chromium.org> wrote:

On Tue, Oct 13, 2015 at 8:37 AM, Rick Byers <rby...@chromium.org> wrote:

On Tue, Oct 13, 2015 at 11:33 AM, Evan Stade <est...@chromium.org> wrote:

On Tue, Oct 13, 2015 at 12:05 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Could somebody summarize what has changed since the last time where Peter was opposed to removing this API?

It was agreed that we should measure usage and go through the formal removal process. This thread contains more info than the last:

1) concrete explanation of differences to <link>

2) overview of implementation status in other browsers

3) promise of instrumentation

I'd personally prefer to have that number before making a decision on deprecation - we want to avoid spammy deprecation warnings. 

I just did a quick httparchive search and found this API used on ~516 of the top 200k websites, including Google.com (and each geo variant of it).  So perhaps the first step is at least understand the implication of the change on some of these sites.  Does the user experience degrade at all? For google.com in particular (or other similarly major websites), we should probably engage with the site owners first about removing their usage of the API.

That data is a year old, and I expect the trend to be downwards: for example google.com doesn't appear to use it any more.

I didn't verify the code is hit, but it's definitely still being served (found with devtools search-across-files):

            try {

                c = "/homepage/search/js/google-secure.xml";

                "https:" != window.location.protocol && (c = "/homepage/search/js/google.xml");

                window.external.AddSearchProvider(c);

                a.A = (new Date).getTime();

                a.w = 0;

                var d = (0,_.u)(Xr.prototype.B, a);

                window.setTimeout(d, 500)

            } catch (e) {

                a.o.log(e)

            }

 

Plus, a lot of those uses don't actually work, if I'm interpreting the columns correctly. If the page and URL don't share the same domain, Chrome will ignore it. This is even part of the WhatWG spec:

No, the 'url' column isn't the argument passed to AddSearchProvider (that wouldn't be statically determinable in general - eg. in the above code).  It's the specific resource where the reference was found.  The 'page' column is the top-level entry (from the Alexa Top 200k sites list).

"""

The OpenSearch description document has to be on the same server as the script that calls this method.

"""

Then there are some sites like animup.net which don't work for various other reasons (like calling the API from an onclick on <option>, which doesn't work). There are a few examples from that doc which do work: http://izlesem.org/, http://gegenteil-von.com/ etc. and these appear to be replaceable with <link rel="search">.

I would like to instrument this feature with UseCounter, but that doesn't seem straightforward because of implementation details (it's a v8 extension, not part of core blink).

Ugh, that's annoying.  If it's not easy to wire up UseCounter specifically, perhaps a separate custom UMA (using a similar mechanism of reporting exactly once per page load - used or not used) would be sufficient and easy?

 

> And what about external.IsSearchProviderInstalled(url)? Why bother keeping it?

Good question, I was going to add a use counter there too. IE has deprecated it as well, but it seems less clear that it's unused.

Given Jochen's comments, any thoughts on how to evaluate the real usage of AddSearchProvider if we don't also disable/remove IsSearchProviderInstalled?

[Jochen Eisinger]

Do we meanwhile have enough data to draw a conclusion here?

[Evan Stade]

As far as I know, Blink use counters are broken[1], so we don't have data from that yet.

On the Chrome side, our uma shows exceedingly low usage[2], around 0.0015% of (dev channel) users per day. (This histogram only just hit beta because the original implementation was buggy.)

[1] https://code.google.com/p/chromium/issues/detail?id=513059

[2] https://uma.googleplex.com/p/chrome/usage/?q=%7B%22Tab%22%3A%22%23timeline-tab%22%2C%22HistogramBuckets%22%3A%7B%22Search.AddSearchProvider2.A%20confirmation%20dialog%20was%20shown%22%3Atrue%7D%2C%22Platform%22%3A%22Windows%22%2C%22Channel%22%3A%22Dev%22%7D

-- Evan Stade

[elaw...@google.com]

Is the counter mentioned above counting the number of installations of search providers, or the number of usages of providers installed via the AddSearchProvider API? It seems like the latter is more reflective of the value of the API. (I only install and configure my browser once, even if I use it 24/7).

  

> concrete explanation of differences to <link>

 

I think I missed that explanation; I saw "<link rel="search"> takes care of most use cases" but I don't understand how that maps to the end-user experience. Is there something about the link element that allows the user to know that a provider is available and install it, potentially setting options at that time?

 

I'm not sure about the methodology used for generating the list of affected sites, but I didn't see DuckDuckGo on the list, and they're still calling AddSearchProvider on their homepage. 

A reference to the IsSearchProviderInstalled API is included in a script used on the Google homepage.

-Eric

[Evan Stade]

So both ExternalIsSearchProviderInstalled and ExternalAddSearchProvider have exceedingly low usage according to chromestatus.com, and Chrome's UMA agrees. Safari, IE, Edge, and mobile Chrome already don't support this feature. Is there any more evidence we need to collect before making a decision?

-- Evan Stade

[Peter Kasting]

On Thu, Feb 18, 2016 at 3:54 PM, Evan Stade <est...@chromium.org> wrote:

So both ExternalIsSearchProviderInstalled and ExternalAddSearchProvider have exceedingly low usage according to chromestatus.com, and Chrome's UMA agrees. Safari, IE, Edge, and mobile Chrome already don't support this feature. Is there any more evidence we need to collect before making a decision?

Rip it out.

PK 

[Rick Byers]

Yep the use counters are low enough (~0.002%) that I'd support removal with the usual one milestone deprecation period (see UseCounter:countDeprecation).  Especially since there's no support on mobile...
LGTM1

[Eric Lawrence]

Just to be clear here, IE7-IE11 do support this feature. 

I guess none of my questions were deemed worthy of acknowledgement. Sorry for the bother. 

--

Eric Lawrence
Chrome Security

[Rick Byers]

Sorry Eric, I missed that you had outstanding questions (my fault for trying to do this on my phone).  Has any attempt been made to reach out to one of the users of this API?  Anyone aware of requests to make it work on mobile?

[Anne van Kesteren]

On Fri, Feb 19, 2016 at 2:37 AM, Rick Byers <rby...@chromium.org> wrote:
> Sorry Eric, I missed that you had outstanding questions (my fault for trying
> to do this on my phone). Has any attempt been made to reach out to one of
> the users of this API? Anyone aware of requests to make it work on mobile?

Also, I'd still appreciate if someone filed an issue here:

https://github.com/whatwg/html/issues/new

Communicating that you'll be removing standardized features with the
rest of the community is a good move.


--
https://annevankesteren.nl/

[Rick Byers]

Yes for sure, but isn't that premature before we've made a decision on whether or not to actually remove it?

The more I look into this from the perspective of one of the smaller search providers, the more confused I am.  Evan, can you point to a demo of <link rel=search>?  I can't seem to find any.

Here's what the "make DuckDuckGo my default search engine" instructions looks like for Chrome:

Clicking "Here" uses AddSearchProvider.  How exactly would this change with <link rel=search>?

Thanks,

   Rick

[Anne van Kesteren]

On Fri, Feb 19, 2016 at 4:20 PM, Rick Byers <rby...@chromium.org> wrote:
> Yes for sure, but isn't that premature before we've made a decision on whether or not to actually remove it?

If you decide to remove it and the HTML community objects, will you
reverse your decision? It seems entirely reasonable to me to have a
discussion with the wider community even when you're not entirely sure
yet yourself.


--
https://annevankesteren.nl/

[Rick Byers]

I agree a broader discussion is a good idea, filed this issue.  Eg. I'm still pretty confused about the relationship with link rel=search (eg. this test page doesn't seem to give me any way to add DuckDuckGo as a search provider - what am I missing?).

If we decide the functionality is really unnecessary, would we really "remove" the API, or just align it's behavior with mobile browsers and make it a no-op (explicitly allowed by the spec)?

[Jochen Eisinger]

I think if a page serves a result that includes a link rel=search in response to something we deem to be a search, we'll silently add a corresponding search engine entry.

[Evan Stade]

When I go to chrome://settings/searchEngines, I see reams and reams of engines that I didn't ever explicitly add. These are from <link rel="search">

For example, urban dictionary serves this line:

<link href='http://b.udimg.com/osd.xml' rel='search' title='Urban Dictionary Search' type='application/opensearchdescription+xml'>

Jochen is partially right, but I don't think we have to deem it to be a search.  On a fresh chrome profile all I have to do is navigate to urbandictionary.com and I see the search show up in "other search engines" in the aforementioned settings page.

The same is true of duck duck go. All I had to do was navigate there and I got their search engine. They can just remove step one of the process (the other steps are still necessary to set default-ness).

-- Evan Stade

[Rick Byers]

Ah, I see this working now - thanks (not sure why duckduckgo didn't get added when I loaded it earlier).  Ok, I agree that seems strictly better - just eliminates a step from the instructions.

So what about removal vs. making it a no-op (like it is on other browsers)?  I tried simulating the removal and using DuckDuckGo and I get an unhandled exception, but really the instructions still work.  So maybe removal is preferable (for feature detection purposes)?

Rick

[Eric Lawrence]

IMO, if the API is going to be broken, it's probably better to remove it than keep it there in neutered form; sites already should be feature detecting on the API so hopefully they won't point users down non-working codepaths.

[bsst...@gmail.com]

Hi, I'm a front-end engineer at DuckDuckGo.

We're fine with removing AddSearchProvider assuming the <link rel="search"> continues to function as it does today (making DDG available as a search engine when people land on our homepage, without requiring them to first doing a search).

I'll remove that first step from our install instructions now.

Thanks for reaching out. Let me know if we can help with anything else here.

Brian

[Rick Byers]

Thanks for following up Brian, glad to hear this change works for you!

Note that we're also talking about adding UI for setting a custom default search engine in Chrome Android (similarly based on the <link rel=search>).  Feel free to chime in on that bug if you have any input.

Still LGTM2 to deprecate and remove, one more?

Rick

[Jochen Eisinger]

lgtm3

[d...@bikeshed.us]

I just read through this thread but it's not clear to me whether a solution is available to install a search provider as part of an extension. There's a reference to use cases not met by <link rel> but no discussion of this one particularly. I develop an extension for my company's internal resources and want to add search as one of the extension's benefits. I do not want to add search to all potential customers by putting this on our domain's top level page, and I don't want users who have already elected to install a company extension to take distinct action to install search providers on company computers.

Would creating a dummy domain with <link rel="search"> on its index document be a suitable workaround, if called from an iframe in the extension's background page?

On Monday, October 12, 2015 at 6:39:57 PM UTC-7, Evan Stade wrote:

Primary eng (and PM) emails

od...@google.com, est...@chromium.org, pkas...@chromium.org

Summary

We plan to remove support for window.external.AddSearchProvider

Motivation

We think this feature doesn't get much usage and is largely redundant with <link rel="search">

Compatibility Risk

Chrome: Desktop Chrome supports this feature but mobile (both Android and iOS) does not

IE: This feature was supported in IE7-9 but deprecated in IE10+ and not present in Edge.

FF: the feature has existed in firefox since FF2 and is still supported in FF41.

Safari: no support

Alternative implementation suggestion for web developers

<link rel="search"> takes care of most use cases. In Chrome's current implementation, <link> will only work for toplevel pages (e.g. example.com but not example.com/faq). It also permits just one search engine per domain (AddSearchProvider allows multiple search engines for the same domain with user consent).

Usage information from UseCounter

This feature is not yet instrumented. I plan to add instrumentation shortly.

OWP launch tracking bug

http://crbug.com/542487

Entry on the feature dashboard

None right now. Does this change merit outreach?

Requesting approval to remove too?

Yes

-- Evan Stade

[Jochen Eisinger]

In an enterprise environment, I'd recommend to use domain policies to configure search engines for a subset of your users.

Best
Jochen

[d...@bikeshed.us]

That's a good idea for users of managed domains. But in this case I'm aiming at users of systems that are not managed by a domain.

[Evan Stade]

On Tue, Mar 15, 2016 at 11:56 AM, <d...@bikeshed.us> wrote:

I just read through this thread but it's not clear to me whether a solution is available to install a search provider as part of an extension. There's a reference to use cases not met by <link rel> but no discussion of this one particularly. I develop an extension for my company's internal resources and want to add search as one of the extension's benefits. I do not want to add search to all potential customers by putting this on our domain's top level page, and I don't want users who have already elected to install a company extension to take distinct action to install search providers on company computers.

Would creating a dummy domain with <link rel="search"> on its index document be a suitable workaround, if called from an iframe in the extension's background page?

Perhaps I misunderstand the problem statement, but why can't you make the extension insert a <link> in your company's page?

I don't know the exact behavior you're after, but you might be better served by this extension API: https://developer.chrome.com/extensions/omnibox

[d...@bikeshed.us]

On Tuesday, March 15, 2016 at 12:13:15 PM UTC-7, Evan Stade wrote:

On Tue, Mar 15, 2016 at 11:56 AM, <d...@bikeshed.us> wrote:

I just read through this thread but it's not clear to me whether a solution is available to install a search provider as part of an extension. There's a reference to use cases not met by <link rel> but no discussion of this one particularly. I develop an extension for my company's internal resources and want to add search as one of the extension's benefits. I do not want to add search to all potential customers by putting this on our domain's top level page, and I don't want users who have already elected to install a company extension to take distinct action to install search providers on company computers.

Would creating a dummy domain with <link rel="search"> on its index document be a suitable workaround, if called from an iframe in the extension's background page?

Perhaps I misunderstand the problem statement, but why can't you make the extension insert a <link> in your company's page?

My goal is to install the search as transparently as possible, when the extension updates, without taking anyone to an extra page. (Nobody ever visits our main site internally; it's customer-facing.) If I need to somehow load a page with a <link> I can work it out, I just needed to know that's what I need to do.

 

I don't know the exact behavior you're after, but you might be better served by this extension API: https://developer.chrome.com/extensions/omnibox

Thanks, that's interesting. It could work, and it's a good tip for anyone else like me who stumbles onto this discussion in a panic. :)

[John Abd-El-Malek]

Given that AddSearchProvider is gone, and IsSearchProviderInstalled's usage is below 0.03, can the latter be removed as well as was discussed in this thread (but no decision reached from what I can tell)?

I noticed this because looking at the code, it's in need of simplification. The implementation was originally servicing the sync IPC on the IO thread to avoid deadlocks. That lead to some complicated thread safe objects. Then sometime since that was added six years ago, it now dispatches to the UI thread indirectly anyways. The chance for deadlock is gone since we don't have NPAPI anymore.

So rather than invest more effort in cleaning up this code, we could just remove it if it has little usage and it's deprecated in IE?

[Domenic Denicola]

From: j...@google.com [mailto:j...@google.com] On Behalf Of John Abd-El-Malek

> Given that AddSearchProvider is gone, and IsSearchProviderInstalled's usage is below 0.03, can the latter be removed as well as was discussed in this thread (but no decision reached from what I can tell)?

FWIW they are both no-ops in the spec now. https://html.spec.whatwg.org/multipage/obsolete.html#external with discussion at https://github.com/whatwg/html/issues/713 and https://github.com/whatwg/html/pull/1108.

[Philip Jägenstedt]

Hmm, it looks like spec and implementation moved in different directions here. external.AddSearchProvider() went away in M52, which is now reaching stable.

How about just going with the spec, adding back AddSearchProvider() but as a no-op alongside a no-op IsSearchProviderInstalled()?

[John Abd-El-Malek]

That sounds good. I have a local change where I made IsSearchProviderInstalled return 2 like IE. I could also add a no-op AddSearchProvider.

One thing that's odd is this code is currently in chrome/renderer. Seems like this should move to blink right?

[Philip Jägenstedt]

Yeah, implementing it with exactly the IDL that the spec has sounds good, if that works we can call it a day and leave it like that forever. 

[Daniel Cheng]

Yes, there's actually an open bug on me to move it into Blink. At the time, I suspended work on it because we thought it was going away completely. Since it looks like it's staying around, I'll just move it over.

Daniel

[PhistucK]

Chrome automatically adds the search engine if you specified it in a <meta> (and maybe if you use it once, I do not remember) using an OpenSearch manifest.

There is no JavaScript based API for explicitly adding a search engine, no.

☆PhistucK

On Tue, Oct 18, 2016 at 1:17 PM, <bob.b...@gmail.com> wrote:

Has something replaced the functionality of AddSearchProvider?

Bob

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Bob Badgett]

I have a web page that lists a number of medical browser search plugins (http://sumsearch.org/searchplugins/).  Worked well on Chrome till recently through AddSearchProvider, still works in other browsers. Sounds like I need to convert to using Omnibox apps through the Chrome store.

Bob

--

Bob

[Peter Kasting]

On Tue, Oct 18, 2016 at 2:55 PM, Bob Badgett <bob.b...@gmail.com> wrote:

I have a web page that lists a number of medical browser search plugins (http://sumsearch.org/searchplugins/).  Worked well on Chrome till recently through AddSearchProvider, still works in other browsers. Sounds like I need to convert to using Omnibox apps through the Chrome store.

Omnibox apps have problems.  Generally, the best solution is to simply send users to a page that has the actual search box in question, ideally with appropriate link rel=search tags on that page.  It's also easier for users to reuse a flow like "this page has a search engine for useful site X, and the omnibox can automatically tab-to-search when you start typing the page in" than it is to have them add search engines from a directory and try and trigger them with manual keywords.

PK

[Lucas Garron]

On Tue, Oct 18, 2016 at 4:09 AM PhistucK <phis...@gmail.com> wrote:

Chrome automatically adds the search engine if you specified it in a <meta> (and maybe if you use it once, I do not remember) using an OpenSearch manifest.

There is no JavaScript based API for explicitly adding a search engine, no.

Any chance you mean <link>, not <meta>?

(I'm hoping to add overdue security requirements to Chrome's OpenSearch support, and want to make sure there aren't things I don't know about.)

 

☆PhistucK

On Tue, Oct 18, 2016 at 1:17 PM, <bob.b...@gmail.com> wrote:

Has something replaced the functionality of AddSearchProvider?

Bob


On Friday, July 22, 2016 at 10:06:08 PM UTC-5, Daniel Cheng wrote:

Yes, there's actually an open bug on me to move it into Blink. At the time, I suspended work on it because we thought it was going away completely. Since it looks like it's staying around, I'll just move it over.

Daniel

On Sat, Jul 23, 2016 at 10:25 AM John Abd-El-Malek <j...@chromium.org> wrote:

That sounds good. I have a local change where I made IsSearchProviderInstalled return 2 like IE. I could also add a no-op AddSearchProvider.

One thing that's odd is this code is currently in chrome/renderer. Seems like this should move to blink right?

On Fri, Jul 22, 2016 at 5:49 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Hmm, it looks like spec and implementation moved in different directions here. external.AddSearchProvider() went away in M52, which is now reaching stable.

How about just going with the spec, adding back AddSearchProvider() but as a no-op alongside a no-op IsSearchProviderInstalled()?

On Fri, Jul 22, 2016 at 2:54 PM Domenic Denicola <d...@domenic.me> wrote:

From: j...@google.com [mailto:j...@google.com] On Behalf Of John Abd-El-Malek

> Given that AddSearchProvider is gone, and IsSearchProviderInstalled's usage is below 0.03, can the latter be removed as well as was discussed in this thread (but no decision reached from what I can tell)?

FWIW they are both no-ops in the spec now. https://html.spec.whatwg.org/multipage/obsolete.html#external with discussion at https://github.com/whatwg/html/issues/713 and https://github.com/whatwg/html/pull/1108.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Peter Kasting]

On Tue, Oct 18, 2016 at 5:19 PM, 'Lucas Garron' via blink-dev <blin...@chromium.org> wrote:

On Tue, Oct 18, 2016 at 4:09 AM PhistucK <phis...@gmail.com> wrote:

Chrome automatically adds the search engine if you specified it in a <meta> (and maybe if you use it once, I do not remember) using an OpenSearch manifest.

There is no JavaScript based API for explicitly adding a search engine, no.

Any chance you mean <link>, not <meta>?

(I'm hoping to add overdue security requirements to Chrome's OpenSearch support, and want to make sure there aren't things I don't know about.)

I think he meant <link rel=search> but honestly I would really like to know what our precise algorithm for auto-sniffing search engines is today.

PK 

[Lucas Garron]

From what I know (including a bunch of testing), https://www.chromium.org/tab-to-search is still accurate, although we tend to be lenient on a lot of details.

»Lucas

[PhistucK]

Yes, I have not used it, so I do not remember the exact element - sorry for the misinformation.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Lucas Garron]

Excellent; thanks for confirming.

In that case, I believe the wiki page is up to date and complete now. But then, I haven't touched the code directly in any significant way.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.