OpenSearch: plugin not added if description not in utf-8 encoding

VERIFIED FIXED in Firefox 3 alpha5

Status

()

Firefox
Search
P1
minor
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: Anton Yuzhaninov, Assigned: Gavin)

Tracking

Trunk
Firefox 3 alpha5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Firefox don't add search plugin if xml description document has not utf-8 encoding

Workaround to this bug: use description document in utf-8

Reproducible: Always

Steps to Reproduce:
1. Create OpenSearch description document in encoding windows-1251 (<?xml version="1.0" encoding="windows-1251"?>)
2. Create web page with link to this description
3. Try to add this search plugin
Actual Results:  
Nothing

Expected Results:  
New search plugin added to search toolbar

In error console I can see:
Error: [Exception... "'Failure' when calling method: [nsIStreamListener::onStopRequest]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "<unknown>"  data: no]
Assignee: nobody → gavin.sharp
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

11 years ago
Same problem here (with iso-8859-1). The opensearch debug log says:
bytesToString: converting using charset: UTF-8, while I have specified iso-8859-1 in the XML prolog and in the HTTP header.

Comment 2

11 years ago
The problem lies in line number 1198 of file mozilla/browser/components/search/nsSearchService.js: UTF-8 is hardcoded. I'm not experienced with the Mozilla source, so I don't know how to change this to the actual charset.
Is there any reason you can't just use UTF-8? We can probably use the encoding from the HTTP header without too much difficulty, but using the encoding from the prolog is going to be a lot more difficult, I believe. I also worry that using the encoding from the header will cause more problems than it solves, due to badly configured HTTP servers.
OS: Windows XP → All
Hardware: PC → All

Comment 4

11 years ago
The reason why I can't control the character set is because I develop a plugin for the forum software vBulletin. This plugin adds OpenSearch description functionality to the vBulletin forum software, and has to use the character set used by the particular forum installation used by someone who uses my plugin. How can the character set from the prolog not be used? When accessing the XML directly the DOM parser is able to use the prolog character set properly, why wouldn't this be possible when reading the XML in this situation?
And I think that badly configured HTTP servers shouldn't be considered: currently there is no way to control the mozilla behaviour, and by reading the HTTP header mozilla at least gives the ability to control the behaviour.
This turned out to actually be an easy bug to fix, I'm sorry I didn't get to it sooner.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox 3 alpha5
Created attachment 263374 [details] [diff] [review]
patch
Attachment #263374 - Flags: review?(mano)
Comment on attachment 263374 [details] [diff] [review]
patch

r=mano
Attachment #263374 - Flags: review?(mano) → review+
Whiteboard: [checkin needed]
mozilla/browser/components/search/nsSearchService.js 	1.94
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Version: unspecified → Trunk

Updated

10 years ago
Duplicate of this bug: 410499

Updated

10 years ago
Duplicate of this bug: 410499
Verified per bug 410499 comment 4
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.