When sending page from the Browser you have to be sure what encoding was used because the Mail composition window doesn't have an autodetect option and ISO-8859 will be used as a default. You have to chose the right encoding otherwise you'll get "This message contains chars not found in the chosen Character Coding" and the page will be displayed incorrectly. It's easy to guess the char set for the languages that have only one encoding but for those that have multiple (Cyrillic, chinese, japanese) it might not be a case. There is certainly a workaround because when you display the page in the browser the encoding is detected (and shown with a checkmark) but it's not remembered in the Composition window and you have to chose again.

I am not so sure whether Send Page should inherit the character codings from the browser window unlike the case of mailto: (bug 57747). These are quite different situations. The fundamental problem is that it is very confusing for an average user to see what is happening, because what you are typing and what you see in the browser window look no different. Maybe mail composition should also go through Autodetect logic on Send and ask user to choose between the two (default and autodetected) when there is a conflict, instead of just warning in a vague manner. At the very least, considering the impending schedule, the charset warning text should include the instruction to change the character codings after you go back to compose window.

The detection only to be applied to attachments, if we implement this feature. For the main body charset, mail send default is used. We currently parse META charset tag in HTML and put that charset in the part header. And the main body charset is not affected by that. Anyway, I think more detail spec needed for this feature.

Mass change to bugs filed by marina --> QA contact to marina. thanks!