Closed
Bug 315533
Opened 19 years ago
Closed 12 years ago
composer generating wrong charset meta-data
Categories
(SeaMonkey :: Composer, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: egmont, Unassigned)
Details
User-Agent: Opera/8.5 (X11; Linux i686; U; en) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051107 Sometimes, when using manual charset selection and undo in the composer, the generated html files will have a meta tag telling that they are in ISO-8859-1, even though the actual encoding of the file is UTF-8. Reproducible: Always Steps to Reproduce: Launch mozilla -editor. (Optional: click on the bottom tab at the bottom of the window to see the source, it says "... charset=ISO-8859-1". Click back to normal mode.) Go to View -> Character Encoding. Here ISO-8859-1 is active. Select UTF-8. (Optional: check the source, it now mentions UTF-8.) Press ^Z (undo). (Optional: check the Character Encoding menu, it still says UTF-8. Take a look at the source view, it now contains ISO-8859-1!!!) Type a few accented letters. Then save the file and examine it with some simple text editor. Actual Results: The saved file is actually encoded in UTF-8, but the meta tag says its character set is ISO-8859-1. Hence this file won't be displayed correctly in any browser. Expected Results: The composer should _never_ generate a html file that specifies a false character set. E.g. if I press the key on my keyboard that produces an o with double acute, and hence I see an o with a double acute on it on my screen, then mozilla _must_ under all circumstances create a html file that mentions an o with a double acute there, so that all browsers will display it correctly. It is of course a nice additional feature to be able to select a character set, but the value of the Content-Type meta tag and the actual encoding of the file must always remain consistent to each other. I have LANG=hu_HU.UTF-8 and no other LC_* variables set.
Comment 1•19 years ago
|
||
FYI, Nvu has this bug also
Comment 2•19 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051108 SeaMonkey/1.5a I don't have to change anything, I'm seeing different settings. Navigator Languages is set to Western(ISO-8859-15), and looking here at View->CharacterEncoding is showing Western(ISO-8859-15) For Mail&Newsgroups->CharacterEncoding, all Options are unchecked, and the default encodings for displaying and composing messages are both set to Western(ISO-8859-1) When I open Composer from here (Ctrl+4 or Window->Composer) and look at View->CharacterEncoding, it tells it is UTF-8 When I select <HTML>source from the footer to see the source code, I'm seeing <meta content="text/html; charset=ISO-8859-15" http-equiv="content-type"> I made two files after looking at encoding in source and View menu, with accented and non-accented chars, and made a third one in a fresh opened composer without looking at encoding, using the french word île. All three files had the default ISO-8859-15 encoding, and the two files with accented characters had manually to be switched to UTF-8 to be seen correctly. So what seems wrong is View->CharacterEncoding showing UTF-8, as this is nowhere specified, and no text had been entered.
Comment 3•16 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; rv:1.9b5pre) Gecko/2008032401 SeaMonkey/2.0a1pre Bug exist also in 1.1.9rc
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•16 years ago
|
||
Can you reproduce with SeaMonkey v2.0a1pre ?
Assignee: composer → nobody
QA Contact: composer
Version: unspecified → SeaMonkey 1.1 Branch
Can't reproduce on trunk, ctrl+z doesn't change encoding and encodings list grayed when I enter something in composer window User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1 Build identifier: 20120712003002
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•