Closed Bug 317165 Opened 19 years ago Closed 17 years ago

problems with charsets in composer

Categories

(SeaMonkey :: Composer, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 369392

People

(Reporter: spam, Unassigned)

Details

(Keywords: regression)

When i open composer and write "זרו", then save and browse, this will display in the browser: ֳ¦ֳ¸ֳ¥ (yen signs and various weird A's) The sourcecode in composer is then this: <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> <title>asd</title> </head> <body> זרו </body> </html> When I look at the character encoding, it is greyed out, but pointing to UTF8 As I initially start to type the first national character, this displays in javascript console: Warning: Key event not available on GTK2: key="a" modifiers="accel, shift" Source File: chrome://editor/content/editor.xul Line: 0 Warning: Key event not available on GTK2: key="d" modifiers="accel,shift" Source File: chrome://navigator/content/navigator.xul Line: 0 Warning: Key event not available on GTK2: key="d" modifiers="accel,shift" Source File: chrome://navigator/content/navigator.xul Line: 0 etc (also a security error as i browse the page: Security Error: Content at about:blank may not load or link to file:///C:/Documents%20and%20Settings/rkaa/Mine%20dokumenter/asd.html.) There is an extra save option under the File menu: "Save and change character encoding", but why should I change it? This bug was also in a build from a month back so it isn't new, but adding regression keyword because I have been able to use composer to write in norwegian with before. If this sorts under internationalization, please reassign.
current build ID Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051117 SeaMonkey/1.5a
Similar to bug 315533
Severity: normal → major
I noticed that when I start composer fresh the first time and write english, then look at the View->Character Encoding, all but UTF8 and ISO 8859-1 is disabled. UTF8 seems to be selected. If i then switch to the source tab the code there indicates i write in iso 8859-1. And when I then switch back to NOrmal view and look at the character encoding again, it is all greyed out - nothing can anymore be selectged. No errors appear in JS console at this point. But I get an error already when insering a space afterwards: Warning: Key event not available on GTK2: key="a" modifiers="accel, shift" Source File: chrome://editor/content/editor.xul Line: 0
This bug is also in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b
Flags: blocking-seamonkey1.0?
As there's no patch, and we have no people actively doing Composer work at the moment, I'll treat it as a step-child (sorry) and not block 1.0 release for that. We'd really need someone to actively care about SeaMonkey Composer again! If a patch pops up, we'd be happy to take it for 1.1, possibly even 1.0.x releases.
Flags: blocking-seamonkey1.0? → blocking-seamonkey1.0-
Bug 384485 may be a duplicate of this one. Is it possible that this has been fixed in the trunk? Using Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9a9pre) Gecko/2007103102 SeaMonkey/2.0a1pre, the default character encoding shows up correctly with View->Character Encoding when starting to compose a new page, and changing it to UTF-8 will correctly store it with "charset=UTF-8". Display in browser is ocrrect too. Selecting the encoding is only possible before typing any text, afterwards the options are grayed out.
There were two issues here. The first was that the about:blank page was changed from using your default charset to using UTF-8. The second was that the serialiser was changed to output the correct META tag even if the wrong one was in the document. Anyway, this is now fixed on trunk and branch via bug 369392.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.