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)
Core
Internationalization
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.
Reporter | ||
Updated•23 years ago
|
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
Comment 1•23 years ago
|
||
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.
Updated•23 years ago
|
Keywords: regression
Comment 2•23 years ago
|
||
shanjian: recall any changes related to this?
Assignee: yokoyama → shanjian
Updated•22 years ago
|
QA Contact: teruko → ylong
Reporter | ||
Comment 4•22 years ago
|
||
I think this problem was resolved by fixing bug 162239, and it not reproducible
on latest branch/trunk build.
Comment 5•20 years ago
|
||
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
Comment 7•20 years ago
|
||
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 → ---
Comment 8•20 years ago
|
||
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
Updated•15 years ago
|
QA Contact: amyy → i18n
Comment 9•9 years ago
|
||
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.
Comment 10•3 years ago
|
||
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)
Comment 11•3 years ago
|
||
This menu is no longer available. Marking the bug as invalid.
Status: NEW → RESOLVED
Closed: 20 years ago → 3 years ago
Resolution: --- → INVALID
Comment 12•3 years ago
|
||
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.
Description
•