ASCII values 127 - 168 are being encoded as question marks on form submission. This does not happen on IE or Nav4.x. Currency symbol for Euros, British Pounds, and Japanese Yens, among other characters like Š(138), š(154), Œ(140), œ(156), and Ÿ(159), get corrupted during form submission, which will impact a lot of international users. The testcase at the url above illustrates the problem.
I think necko does the necoding, is that right? reassiging
Assignee: rods → pollmann
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
It looks like the string is converted to question marks by nsEncoderSupport::Convert, which is called by URLEncode inside of nsFormFrame. ??? Perhaps we should be manually URL encoding the string to prevent this from happening?
Even before we the characters are all converted to question marks, they are aparently wrong - the string looks like this: .?...........?.??............?.. when we fetch it from the text control frame. Perhaps the problem is there?
Component: Form Submission → HTML Form Controls
adding keywords; copying Frank and Erik
Keywords: intl, nsbeta1
This bug may be "invalid." In HTML 4.01, form input is restricted to the US-ASCII charset unless enctype="multipart/formdata" is specified. See http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4
Erik is this bug still valid? Need your assessment.
There's also bug 70838 on this issue.
Jaime, please ask a QA person to test this in MSIE, Netscape 4.X and Mozilla. I tried to take a look at the URL above, but that page doesn't seem to be there any more. Perhaps vladimire would know about this?
This is still happening. Sorry the testcase was renamed, I am updating the url.
changing to nsbeta1-.
Keywords: nsbeta1 → nsbeta1-
Per Vishy's request, setting priority P2, so that we can triage.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Moving to Mozilla0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
Status: ASSIGNED → NEW
Summary: ASCII values 127 - 168 are not encoded correctly → ASCII values 127 - 168 are not encoded correctly [form sub]
performed test on URL with mozilla trunk pull from 10-29-2001 and the test passed marking WORKSFORME please verify thx
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
COOL! I am so happy this is fixed! Verifying on 2001-11-01-03 trunk and linux 2001-10-31-08-trunk :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.