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

RESOLVED WONTFIX

Status

()

Firefox
Search
--
enhancement
RESOLVED WONTFIX
12 years ago
5 years ago

People

(Reporter: Pam Greene, Unassigned)

Tracking

2.0 Branch
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox2 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
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).
(Reporter)

Comment 1

12 years ago
Sorry, second reference in comment #1 should be to bug 335102, not 335012.
Severity: normal → enhancement
Flags: blocking-firefox2?
Whiteboard: [swag: 1d] after blocking bug gets fixed
Target Milestone: Firefox 2 → Firefox 2 beta1
(Reporter)

Updated

12 years ago
Blocks: 335435
plussing for now, but its lowest-priority of the search bugs I've read thus far.
Flags: blocking-firefox2? → blocking-firefox2+
(Reporter)

Updated

12 years ago
Depends on: 340331
No longer depends on: 335102
(Reporter)

Updated

12 years ago
Priority: -- → P4
since bug 340331 is wontfixed, minusing this
Flags: blocking-firefox2+ → blocking-firefox2-
(Reporter)

Comment 4

12 years ago
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.
(Reporter)

Comment 5

12 years ago
Created attachment 228757 [details] [diff] [review]
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.
(Reporter)

Updated

12 years ago
Whiteboard: [swag: 1d] after blocking bug gets fixed → [swag: 1d]
(Reporter)

Updated

12 years ago
Priority: P4 → P2
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
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?
(Reporter)

Comment 7

12 years ago
Created attachment 229190 [details] [diff] [review]
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.
Attachment #228757 - Attachment is obsolete: true
Attachment #229190 - Flags: review?(mconnor)
Created attachment 229197 [details]
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.
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 :)
(Reporter)

Comment 10

12 years ago
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.
Attachment #229190 - Flags: review?(mconnor)
(Reporter)

Updated

12 years ago
Depends on: 334875
(Reporter)

Updated

12 years ago
Priority: P2 → --
Renominating, IE has this and I wouldn't be surprised if the following becomes a common script:

if (!window.external.IsSearchProviderInstalled(...))
  window.AddSearchProvider(...);
Flags: blocking-firefox2- → blocking-firefox2?
Summary: New JS API to allow sites to tell whether their engines are already in the list → Implement IE's window.external.IsSearchProviderInstalled (New JS API to allow sites to tell whether their engines are already in the list)
Whiteboard: [swag: 1d] → http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/issearchproviderinstalled.asp
Whiteboard: http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/issearchproviderinstalled.asp
Target Milestone: Firefox 2 beta2 → Firefox 2
(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).
(Reporter)

Comment 13

11 years ago
(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.
Not blocking on this, but we will go with gavin's suggestion in comment 12.

filed Bug 351857 to track that for Fx2
Flags: blocking-firefox2? → blocking-firefox2-
(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.
(Reporter)

Comment 16

11 years ago
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.
(Reporter)

Updated

11 years ago
Assignee: pamg.bugs → nobody
Target Milestone: Firefox 2 → Firefox 3

Updated

9 years ago

Comment 17

9 years ago
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.
Duplicate of this bug: 153509
No longer blocks: 335435
Target Milestone: Firefox 3 → ---
Depends on: 518929
Depends on: 610714
No longer depends on: 334875

Comment 19

6 years ago
Hi, any news about implementation of this api?
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.