Closed Bug 126334 Opened 23 years ago Closed 3 years ago

The charset is not followed the one that specified when input form submission

Categories

(Core :: Internationalization, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID
mozilla1.1alpha

People

(Reporter: amyy, Unassigned)

References

()

Details

(Keywords: intl, regression)

Build: 02-18 trunk build Steps: 1. Launch browser with a new profile and go to: http://cgi-lib.berkeley.edu/ex/simple-form.html 2. View | Character Coding, select a desire charset, e.g. any Japanese or Chinese charset. 3. Type some characters (JA or CN) into the fields. 4. Click on "here" button to submit. Result: Will bring up a page, but those input characters are displayed garbled The charset of result page will marked as western (iso-8859-1). Manually correct the charset will get the character displayed fine in result page. Note: N6.2.1, the result will has the same charset as before submit, and characters are displayed fine.
Keywords: intl
QA Contact: ruixu → teruko
Summary: The charset is not followed the one specified in form submission → The charset is not followed the one that specified when input form submission
After you submit the form, the form does not remember the character coding was before. For example, 1. Default charset is Western (ISO-8859-1) 2. Go to above url 3. Changed the character coding to Japanese (Shift_JIS) 4. Type any Japanese character in the forms and click on submit Japanese characters are displayed as garbage. When you check the character coding menu, the menu Western (ISO-8859-1) is marked. In 6.21, Japanese (Shift_JIS) is marked and displayed correctly.
Keywords: regression
shanjian: recall any changes related to this?
Assignee: yokoyama → shanjian
accept.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
QA Contact: teruko → ylong
I think this problem was resolved by fixing bug 162239, and it not reproducible on latest branch/trunk build.
shanjian is no longer working on mozilla for 2 years and these bugs are still here. Mark them won't fix. If you want to reopen it, find a good owner first.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Mass Reassign Please excuse the spam
Assignee: shanjian → nobody
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all the spam is his fault feel free to tar and feather him
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
QA Contact: amyy → i18n
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0 The issue is still reproducible on the latest Firefox Release (46.0, Build ID 20160421124000) and the latest Nightly (49.0a1, Build ID 20160427030215). I can confirm that the described behavior from comment 1 is still an issue.

The bug assignee didn't login in Bugzilla in the last 7 months.
:m_kato, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: jshin1987 → nobody
Flags: needinfo?(m_kato)

This menu is no longer available. Marking the bug as invalid.

Status: NEW → RESOLVED
Closed: 20 years ago3 years ago
Resolution: --- → INVALID

Although I cannot find same issue, I believe that this issue is already fixed before removing encoding menu.

Flags: needinfo?(m_kato)
You need to log in before you can comment on or make changes to this bug.