User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Build Identifier: If you download the Firefox Sync Key in a HTML File (preferences > Sync > My sync key > save…), the file doesn't include information about file-encoding. So Firefox may try to open the file as Latin1 in place of UTF-8. Reproducible: Always

This is maybe no problem for users of an english version of Firefox, but in localized builds there may be troubles. For exampel in Romansh (rm).

Sorry, I didn't about searching an existing bug, since it looks like a very quick fix to do. If I'm not missing something obvious, the attached patch should be enough to fix the problem.

Adding other localizers to this bug, no idea who I should request review for this patch.

Comment on attachment 496770 [details] [diff] [review] Patch to add character enconding to head section Philip?

The changes should be fine as far as locales are concerned.

I will gladly r+ if we can ensure that the file always gets written as UTF-8. I have no idea whether that's always the case on all of our platforms and all their locales.

No idea how you actually save, tbh. Poke someone from the content team?

Comment on attachment 496770 [details] [diff] [review] Patch to add character enconding to head section I just had a look at the code (my code in fact :p). Yes we always save as UTF-8. r=me

Comment on attachment 496770 [details] [diff] [review] Patch to add character enconding to head section Using addl. review flag in lieu of the missing approval flag.

(In reply to comment #9) > Comment on attachment 496770 [details] [diff] [review] > Patch to add character enconding to head section > > I just had a look at the code (my code in fact :p). Yes we always save as > UTF-8. r=me :-)

This is bogus. This is an XML file, and has had its encoding defined in the right way forever: 1 <?xml version="1.0" encoding="UTF-8"?> The line this patch added is wrong and will never be taken into account. Please back out.

How would you explain the screenshot then?

I'd guess the HTML5 renderer is at fault: Render Mode, Encoding from Page Info: - html5.enable=true: Quirks Mode, UTF-8 (Minefield; FF 3.5 and 3.6 behavior) - html5.enable=false: Standards compliance mode, ISO-8859-1 (Minefield) This is with a Sync Key file created from a build without the patch from this bug applied.

Henri, can you take a look at comment 15 and the synckey file, https://hg.mozilla.org/mozilla-central/file/ec119059ab45/browser/base/content/syncKey.xhtml?

So the file is .xhtml in the repo. When the file is processed as .xhtml, the <meta> has no effect. When the user saves a key file, Firefox offers to name it with the .html extension. Once saved as .html, it'll get loaded back as HTML in which case the XML declaration (per HTML5) has no effect. The bug here was offering to export the file as .html when the content is XHTML, but with the patch that got landed, things should work when the file is loaded as .html. It's a bit embarrassing that we save XHTML 1.0 into .html instead of saving HTML into .html or XHTML into .xhtml, but I think it's more important to ship that tweak things further.

s/that tweak/than to tweak/

Thanks for clarifying, Henri! (In reply to comment #17) > So the file is .xhtml in the repo. When the file is processed as .xhtml, the > <meta> has no effect. When the user saves a key file, Firefox offers to name it > with the .html extension. Once saved as .html, it'll get loaded back as HTML in > which case the XML declaration (per HTML5) has no effect. Woah. So Firefox takes the extension over the XML declaration ? That's certainly good to know! > The bug here was offering to export the file as .html when the content is > XHTML, but with the patch that got landed, things should work when the file is > loaded as .html. It's a bit embarrassing that we save XHTML 1.0 into .html > instead of saving HTML into .html or XHTML into .xhtml, but I think it's more > important to ship that tweak things further. Agreed, hence marking this as fixed again. If we really care enough about saving HTML instead of XHTML, we can do that in a follow-up.

(In reply to comment #19) > So Firefox takes the extension over the XML declaration ? The choice of parser depends on the media type (except maybe for syndication feeds). When loading from the local file system, the media type is synthesized from the file name extension.

Verified with latest nightly build