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]
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.
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.
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.
Comment on attachment 263374 [details] [diff] [review] patch r=mano
Verified per bug 410499 comment 4