I need the ability to save ender documents into charsets other than ISO-8859-1. Removing the hardcoded charset information didn't completely solve the problem. I would like to check the attached patch in for M9.

patch looks fine. cc'ing simon and akkana so they can give it a quick look as well, but I'd say it's ok.

Is there a reason we have to save mDocCharset in nsEditor, rather than simply passing the charset through to the Save and SaveAs methods? It's not clear how mDocCharset, and the real charset in the document are kept in synch, or indeed whether they need to be.

I'm not sure I understand this bug or the fix -- is it that we need to be able to tell the editor that even though the document uses charset X, we want all saves to happen in charset Y? Echoing Simon's question -- do we need to save this information in the editor, or can it live in the editor shell or somewhere else? How does the user actually call this functionality -- is this what the editor's charset menu does? I'm okay with the patch if that's what it's supposed to be doing. If the problem is just that we need to follow the document's charset and that's not working right, then I'm with Simon that we shouldn't store the information redundantly inside the editor, but should instead figure out why defaulting the charset string inside nsDocument::SaveFile isn't working properly.

The first problem that we are trying to address is that the international group can't use ender. It is impossible right now to save documents in anything but ISO-8859-1 (latin-1), even webpages that were originally in Japanese. This is a dogfood issue for us. We can't use ender to prepare tests cases and edit documents. All of which are reasons to store the information in the editor. As far as keeping the document character set information in the editor, I have several reasons for doing that. First, looking at most of the xul-javascript in our product, it's stateless -- all of the state information is stored in the xpconnected commponents, not the javascript code. I tried to follow this as a style principle. Second, the nsEditorShell also doesn't really contain any state information about the document that the editor is editing, so it also seems stylistically inappropriate to put the information there. Third, in the future I wan't to programmatically be able to set the 'save as' document character set from the input method and keyboard handing code, which only has access to the nsEditor component not the editor shell. We also want to be able to override the document character set. All languages can be represented in several different encodings, and the user needs to be able to choose which character set to save, regardless of the "original" character set. so, this is tested xp and i'd like to get it in once people are doing clearing out the mail and profile regressions that happened today.

tague: since this is an important blocker, go ahead and check it in. But please continue to work with Akkana and Simon to make sure architectually we're storing the information in the right place. Maybe we should get together briefly Tuesday to hash this out and make sure it's the correct solution. Tague, can you set up a 30 minute meeting Tuesday afternoon?

checked in fix today (8/13/99) with choffman's approval.

Cc'ing teruko and momoi

cc'ing myself...

Now that the menu is in the product, I will also complete other editor UE specs and will deal with them in Bug 7849.

hi tague, can you verufy this one and mark verified-fixed? thanks!

marking verified as requested.