340604 - Implement IE's window.external.IsSearchProviderInstalled (New JS API to allow sites to tell whether their engines are already in the list)

Status: RESOLVED WONTFIX

(Firefox :: Search, enhancement)

Description

[Pam Greene]

In addition to the JS API to let a page ask to be added to the list of available search engines (see bug 337780), we should provide a way for sites to tell whether they're already in that list, so they can choose not to show the UI (e.g., a button) for adding themselves.

Since we'll only want to let sites ask about their own engines, we'll need to be able to identify an engine by something more secure than its title (see bug 335012).

Comment 1

[Pam Greene]

Sorry, second reference in comment #1 should be to bug 335102, not 335012.

Comment 2

[Mike Connor [:mconnor]]

plussing for now, but its lowest-priority of the search bugs I've read thus far.

Comment 3

[Mike Connor [:mconnor]]

since bug 340331 is wontfixed, minusing this

Comment 4

[Pam Greene]

It should still be possible to add this API without too much work, but IMO it's not a high priority and shouldn't block.  Unless anyone disagrees, I'll leave it at P4, which means it likely won't make it in.

Comment 5

[Pam Greene]

Attachment: WIP - needs security

Here's a work-in-progress patch.  Other than review, it mostly needs a check to ensure that a site can only ask whether its own search engine is already installed.  Some discussion about how strict that should be and how it should be implemented would be welcomed.

I'm inclined to think that you can ask about any site that you could write a cookie for.  That's at least a defensible line to draw, but is it too restrictive?  Alternatively, we could require that the hostname of the calling page exactly match the hostname of the engine description file; that would certainly be easier to implement, but it seems rather limiting.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

I'm somewhat skeptical about whether this is really needed - the "don't want to add UI to the page unnecessarily" use-case doesn't seem particularly important to me, given that most sites are in my opinion more likely to use auto discovery than in-page UI. It seems like the cost/benefit ratio for implementing this feature (especially securely) is rather high (the cost being code size/complexity).

Are there use cases I'm not considering?

Comment 7

[Pam Greene]

Attachment: Fixes issue, including cookie-like security

(In reply to comment #6)
> I'm somewhat skeptical about whether this is really needed - the "don't want to
> add UI to the page unnecessarily" use-case doesn't seem particularly important
> to me, given that most sites are in my opinion more likely to use auto
> discovery than in-page UI.

Interesting.  I'd guess that most sites will want to show a more prominent "advertisement" than autodiscovery offers.

> It seems like the cost/benefit ratio for
> implementing this feature (especially securely) is rather high (the cost being
> code size/complexity).

I'm also not sure of the magnitude of the benefit, but the cost doesn't strike me as particularly high either.

On the branch, this patch implements the feature with essentially the same security that cookies have -- admittedly not as secure as we'd like them to be, but nothing new.  On the trunk, it can use the new domain service, which should be an easy, strong test.  (The biggest remaining hole I can see is our inability to know for sure the URL of the page that called the JS function.)

> Are there use cases I'm not considering?

Well, there's some benefit in making our search-engine API as convenient and flexible as possible, to underline the fact that Firefox wants searching to be open and useful.  That's not a strong argument, and I wouldn't use it to support a bad change, but for something relatively simple like this it's at least a small point in favor.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Attachment: testcase

It's nearly impossible to implement this correctly without making changes to how we get the "current URI". This testcase shows an example that gets around the patch's security. I think that a proper solution to bug 334875 is required to implement this correctly.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

I just realized that running the testcase from Bugzilla will of course work for both cases, since it uses addons.mozilla.org as an example, which is also mozilla.org, but I think you get the point :)

Comment 10

[Pam Greene]

Comment on attachment 229190 [details] [diff] [review]
Fixes issue, including cookie-like security

(In reply to comment #8) 
> It's nearly impossible to implement this correctly without making changes to
> how we get the "current URI".

True enough.

Comment 11

[Asaf Romano (gone)]

Renominating, IE has this and I wouldn't be surprised if the following becomes a common script:

if (!window.external.IsSearchProviderInstalled(...))
  window.AddSearchProvider(...);

Comment 12

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #11)
> Renominating, IE has this and I wouldn't be surprised if the following becomes
> a common script:
> 
> if (!window.external.IsSearchProviderInstalled(...))
>   window.AddSearchProvider(...);

I think a new bug should be filed on stubbing this out and always returning false, which is all that we can really do in the Firefox 2 timeframe, so that this bug can be kept for the actual implementation (which is what the attached patch does, minus the security issues).

Comment 13

[Pam Greene]

(In reply to comment #12)
> I think a new bug should be filed on stubbing this out and always returning
> false

I'm not certain which is worse for site designers, having the function not exist or having it not do anything useful.

Comment 14

[Mike Connor [:mconnor]]

Not blocking on this, but we will go with gavin's suggestion in comment 12.

filed Bug 351857 to track that for Fx2

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #13)
> I'm not certain which is worse for site designers, having the function not
> exist or having it not do anything useful.

The point is that having it throw unexpectedly (which is what currently happens, because it doesn't exist) is worse than either of those.

Comment 16

[Pam Greene]

Is it?  If we put in a stub, and site designers use it to decide whether to show some intrusive, presumably-one-time-only "Do you want to add us to your menu?" splash, then we've made their site unusable for our users -- and the designers will have to notice that and create two code paths to support us.  If we don't put in a stub, and we throw, they'll still need two code paths, but at least it'll be immediately obvious.

Comment 17

[Gabriel Weinberg]

Hi, it has been over two years now, and as far as I can tell this still isn't implemented in Firefox 3.  Any chance it can get in?  I am a site owner wanting to use for the above use case, i.e. to decide whether to show a link to add to the search bar.

Comment 19

[Alexey Androsov]

Hi, any news about implementation of this api?

Comment 20

[:Gavin Sharp [email: [e-mail]]]

This was apparently deprecated in Windows 8, per http://msdn.microsoft.com/en-us/library/aa342526(v=vs.85).aspx, so we shouldn't go any further here.