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

VERIFIED WORKSFORME

Status

()

P3
normal
VERIFIED WORKSFORME
18 years ago
17 years ago

People

(Reporter: ji, Assigned: tetsuroy)

Tracking

({intl})

Trunk
mozilla0.9.2
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
***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.

Comment 1

18 years ago
Linux only? I cannot reproduce with 6.0 with Windows 2000 en-US.
(Reporter)

Comment 2

18 years ago
Yes, it is linux only.

Comment 3

18 years ago
I cannot reproduce this with 11-08 MN6 JA and US build on Redhat 6.2JA.

(Reporter)

Comment 4

18 years ago
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.

Comment 5

18 years ago
Reassign to ftang.
Assignee: nhotta → ftang

Updated

18 years ago
Keywords: intl

Comment 6

18 years ago
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong

Comment 7

18 years ago
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
(Assignee)

Comment 8

18 years ago
Is this a duplicate of 56200?  ylong, please verify.
Status: NEW → ASSIGNED

Comment 9

18 years ago
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.
(Assignee)

Comment 10

18 years ago
Linux specific. Please see if you can fix it.
Assignee: yokoyama → bstell
Status: ASSIGNED → NEW

Comment 11

18 years ago
in EditorSaveAsCharset.js line 93 it checks that the charset has been changed
before setting the metacharset.

Frank, could you look at this?

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 12

18 years ago
Juraj, would you please look at this?

thanks
Assignee: bstell → jbetak
Target Milestone: mozilla0.9.2 → ---

Comment 13

18 years ago
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
(Reporter)

Comment 14

18 years ago
Retested with 06-11-08-mtrunk build. The problem doesn't exist anymore.
Resolved it as wfm.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 15

17 years ago
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.