Closed Bug 315533 Opened 19 years ago Closed 12 years ago

composer generating wrong charset meta-data

Categories

(SeaMonkey :: Composer, defect)

SeaMonkey 1.1 Branch
x86
Linux
defect
Not set
normal

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.
FYI, Nvu has this bug also
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.
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
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.