337625 - If an OpenSearch search plugin includes an Url tag with type other than text/html then it doesn't install

Status: RESOLVED FIXED

(Firefox :: Search, defect, P1)

Description

[Paul Millar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060511 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060511 Minefield/3.0a1

If an OpenSearch, (as an OpenSearch description document) plugin includes an Url tag which isn't type="text/html" then it won't install in the search bar. This happens even when there is an Url tag with type="text/html". 

Reproducible: Always

Steps to Reproduce:
1. Goto http://www.edazzle.net/os/
2. Click on the drop down list of search plugins
3. Click on one of tthe Add Amazon entries

Actual Results:  
Download error

Expected Results:  
The search plugin to be added to the search bar drop down list of installed plugins

Installs plugins fine when Url tag attribute type is set to "text/html" and is the only Url tag in the file.

Comment 1

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

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/components/search/nsSearchService.js&rev=1.22#1118

Need to check whether we've already found a valid URL instead of clobbering any existing ones.

Paul: if you want to, you should be able to work around this issue by putting the type="text/html" <URL> last in the plugin files.

Comment 2

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

Attachment: patch

Comment 3

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

mozilla/browser/components/search/nsSearchService.js 	1.1.2.25
mozilla/browser/components/search/nsSearchService.js 	1.31

Comment 4

[Joan Junyent]

I've seen this bug is fixed in the 3.0 branch. But, is it going to be fixed in the 2.0 branch as well?

I'm experimenting the same problem with: Mozilla/5.0 (Windows; U; Windows NT 5.1; ca; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Comment 5

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

(In reply to comment #4)
> I've seen this bug is fixed in the 3.0 branch. But, is it going to be fixed in
> the 2.0 branch as well?

It is fixed on the 1.8 branch (Bon Echo nightly builds), see the "fixed1.8.1" keyword. If you have evidence to the contrary, please file a separate bug?