Closed Bug 60399 Opened 24 years ago Closed 24 years ago

Save as Charset: html body is not saved to iso-2022-jp as specified.

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.2

People

(Reporter: ji, Assigned: tetsuroy)

Details

(Keywords: intl)

***observed with linux 2000-11-08-07 ja build**** When Saving a document to iso-200-jp by selecting File | Save as Charset, it actually is not saved in the charset as expected. Steps to reproduce: 1. Launch Composer. 2. Enter some Japanese and select File | Save as Charset. Be sure that the charset on the Composer is not set to ISO-2022-JP 3. Save the file into html format. 4. Open the file with an editor. You'll see that although the document has a meta tag of ISo-2022-JP, but the body part is actually in EUC.
Linux only? I cannot reproduce with 6.0 with Windows 2000 en-US.
Yes, it is linux only.
I cannot reproduce this with 11-08 MN6 JA and US build on Redhat 6.2JA.
More info: After you select File | Save as Charset, a dialog window comes up. On this window, if you select ISO-2022-JP first and then enter a title for the document, the html page can be saved correctly in ISO-2022-JP. However, if you enter a title first, and then select ISO-2022-JP, you won't get the composer contents saved in ISO-2022-JP.
Reassign to ftang.
Assignee: nhotta → ftang
Keywords: intl
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong
composer problem. Reassign to yokoyama. Mark this as moz 0.9.1 P3. Put nsbeta1 into the keyword.
Assignee: ftang → yokoyama
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
Is this a duplicate of 56200? ylong, please verify.
Status: NEW → ASSIGNED
I have a new comments for bug 56200, so I can't tell if it is dupilicated of that. However, seems I didn't see this on 01-17 Mtrunk Linux build.
Linux specific. Please see if you can fix it.
Assignee: yokoyama → bstell
Status: ASSIGNED → NEW
in EditorSaveAsCharset.js line 93 it checks that the charset has been changed before setting the metacharset. Frank, could you look at this?
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Juraj, would you please look at this? thanks
Assignee: bstell → jbetak
Target Milestone: mozilla0.9.2 → ---
looks pretty bad. reassign to yokoyama. yokoyama, please help to look at this one. try to reproduce this on ji's unix machine. mark it as moz0.9.2 for now.
Assignee: jbetak → yokoyama
Target Milestone: --- → mozilla0.9.2
Retested with 06-11-08-mtrunk build. The problem doesn't exist anymore. Resolved it as wfm.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
I can not reproduce it on 08-24 Linux trunk build. Mark it as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.