ASCII values 127 - 168 are not encoded correctly [form sub]

VERIFIED WORKSFORME

Status

()

--
major
VERIFIED WORKSFORME
18 years ago
17 years ago

People

(Reporter: vladimire, Assigned: alexsavulov)

Tracking

({intl})

Trunk
mozilla0.9.6
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

Comment 1

18 years ago
I think necko does the necoding, is that right? reassiging
Assignee: rods → pollmann

Updated

18 years ago
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9

Comment 2

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

Comment 3

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

Comment 4

18 years ago
adding keywords; copying Frank and Erik
Keywords: intl, nsbeta1

Comment 5

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

Updated

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

Comment 6

18 years ago
Erik is this bug still valid? Need your assessment.

Comment 7

18 years ago
There's also bug 70838 on this issue.

Comment 8

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

Comment 9

18 years ago
This is still happening. Sorry the testcase was renamed, I am updating the url.

Updated

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

Comment 10

18 years ago
changing to nsbeta1-.
Keywords: nsbeta1 → nsbeta1-

Comment 11

18 years ago
Per Vishy's request, setting priority P2, so that we can triage.

Updated

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

Updated

18 years ago
Blocks: 70838

Comment 12

18 years ago
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5
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
(Assignee)

Updated

17 years ago
Summary: ASCII values 127 - 168 are not encoded correctly → ASCII values 127 - 168 are not encoded correctly [form sub]
(Assignee)

Comment 15

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

Comment 16

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