332459 - Edit Item form accepts text as ISO-8859-1 encoding even though page is UTF-8

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[James Ross]

The web pages for UMO^W AMO all declare themselves to be UTF-8. This is fine and good. However, the form submission handling seems to interpret data as ISO-8859-1 (or some other single-byte encoding).

This means that if you enter, say, é (e-acute) you end up with two characters - é (capital A with 'o', copyright). That's the two bytes for the UTF-8 encoding as separate single-byte characters. These two characters are what appears everywhere, both in the edit box and public pages.

The workaround I found for now is that after loading the Item Edit page, to change the browser into ISO-8859-1, enter data and submit, and that will work (if the characters you want work in that charset).

Comment 1

[Rob Marshall [tH]]

I think this is caused by the code in core/inc_global.php, lines 70-79. All values in $_GET and $_POST are passed through (among other things) htmlentities(). This defaults to ISO-8859-1.

"htmlentities(foo)" should be changed to "htmlentities(foo, ENT_COMPAT, 'UTF-8')".

Comment 2

[Robert Kaiser]

Looks like we're running into that in a bigger style with adding dictionaries for Gecko-1.8.1-based applications. If one has non-ASCII characters in install.rdf (correctly encoded as UTF-8), those strings are displayed correctly in the "add item" pages, but then end up garbled up as described in comment 0 when you save them...

Comment 3

[Benjamin Smedberg]

Attachment: Use UTF-8 encoding, rev. 1

Like this, against AMO1 sources.

Comment 4

[Michael Morgan [:morgamic]]

Comment on attachment 230995 [details] [diff] [review]
Use UTF-8 encoding, rev. 1

This looks good, and works fine.

Comment 5

[Michael Morgan [:morgamic]]

Checked in this patch -- we will push this into production along with a fix for bug 346171.