103678 - Editor: unable to change fonts when changing encoding for a new document

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[ji]

Build: 10/08 win32 branch build

On HTML composer, when changing the encoding, it doesn't use the fonts for that
new encoding.

Steps to reproduce:
1. Launch a Japanese build, since the default language of a Japanese build is
set to Japanese and this problem is more obvious with this setting.
2. From Preference, change fonts for Japanese to a much bigger fonts, say size
of 24.
3. Bring up HTML composer window, the default encoding for this window is
Japanese (Shift-JIS) as expected. Before you enter anything, change the encoding
to Western (ISO-8859-1).
4. Enter English in the Composer window, you can see it's still using the font
you selected for Japanese, not the fonts you desired for Western (ISO-8859-1).

Comment 1

[Yuying Long]

What about check the html source? and if you save the document and re-open it
again? 

For my case, the font sets to changed font size, and if I re-open this document,
the font is showing changed font.

The problem here seems it can not be display properly in normal editor and
preview window when first switch to diferent charset other than default.

Comment 2

[Yuying Long]

Actually, we shouldn't change the font for html source, right?

Comment 3

[Yuying Long]

I meant "font size" not "font" in my previous domment.

Comment 4

[ji]

What do you mean by "the font sets to changed font size"?
This problem shows when you open a new HTML composer window and change to a
different encoding. After the page is saved and reopened, it's displayed in the
desired fonts.

Comment 5

[ji]

And before you save and reopen the document, you should also be able to changing
the fonts when you change the encoding.

Comment 6

[Yuying Long]

> What do you mean by "the font sets to changed font size"?

I meant for "changed font/charset" (because in your steps, you changed the font
size in order to make the font change easy to verify).

I'm not quite sure, however I guess it's the same problem as bug 69911 ahthough
they are from different view.  In another word, fix for bug 69911 might fix this
problem.  There should become "dirty" stage when just change the charset(encoding).

Comment 7

[Roy Yokoyama]

->jbetak

Comment 8

[[e-mail] (away - not reading bugmail)]

hmm, this looks like a repaint issue - accepting for now.

Comment 9

[nhottanscp]

Reassign to nhotta.

Comment 10

[nhottanscp]

move to 0.9.8

Comment 11

[nhottanscp]

nsbeta1, bug 103282 needs this

Comment 12

[nhottanscp]

nsbeta1+

Comment 13

[nhottanscp]

nsPlaintextEditor::SetDocumentCharacterSet
http://lxr.mozilla.org/seamonkey/source/editor/libeditor/text/nsPlaintextEditor.
cpp#265
The code handles the charset menu action, creating META charset. But it doesn't 
seem to set font.

Comment 14

[nhottanscp]

I found this is working for editing existing document.

http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/editor.js#489
489 function EditorSetDocumentCharacterSet(aCharset)
490 {
491   if(editorShell)
492   {
493     editorShell.SetDocumentCharacterSet(aCharset);
494     if( !IsUrlAboutBlank(editorShell.editorDocument.location))
495     {
496       // reloading the document will reverse any changes to the META 
charset, 
497       // we need to put them back in, which is achieved by a dedicated 
listener
498       editorShell.RegisterDocumentStateListener( DocumentReloadListener );
499       editorShell.LoadUrl(editorShell.editorDocument.location);
500     }
501   }
502 }

So loading the file after the charset change. 
In case of mail compose (bug 103282), the editing document is "about:blank", so 
we cannot load it or we lose the editing text.
Removing bug 103282 from the dependency, and change to nsbeta1-.

Comment 15

[Kathleen :Brade]

Please forgive me because I am just coming up to speed on this and related issues.

I am concerned about the code snippet in comment 14.  It seems like there can be
data loss if a user opens an existing file in Composer, makes some changes and
then this function gets called.  There really should be a check for the document
state (isModified).  Perhaps if the user has modifications, they should be
prompted to save first before the changes are made? (or we need to fix the real
problem)

I think back in 4.x days, there was an explicit call in the networking code
(iirc) that allowed for charset changes being reloaded without loss of existing
data.  Does that ring any bells with anyone here?

Comment 16

[nhottanscp]

I think that's true, but currently charset menu is disabled after the document
gets dirty. I think there is a bug about that behavior.

Changing the summary, it is specific to a new document.

Comment 17

[nhottanscp]

fixed by bug 103282

Comment 18

[Yuying Long]

Fix verified on 12-17 trunk build on WinME-JA and linux RH7.1-JA.