Closed Bug 375954 Opened 14 years ago Closed 14 years ago

html entities are sent differently from input hidden and textarea from same form

Categories

(Core :: DOM: Core & HTML, defect)

1.8 Branch
x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 218277

People

(Reporter: antti.raikka, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fi; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fi; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

€ is for example different from these two components. This works ok in IE, and that is a shame that FF is worse than IE in something.
<form name="form1" action="brocSubmit.jsp" method="post">
<textarea cols="30" rows="4" name="user_value92">500 000,00 € </textarea>
<input type="hidden" value="500 000,00 € " name="template_value92"/>

Reproducible: Always

Steps to Reproduce:
1. make form with input and textarea components with the same server side filled values '&#8364;'
2. make receiving form and compare the returned values in java (servlet) -> different
3. Try the same in IE -> works like crackers.
Actual Results:  
Debug through the returned strings in (Eclipse)java code and see that they are not the same strings.

Expected Results:  
The returned string should be the same in both textarea and input returned values.

If this is my error, please do correct me and point me to the right direction.
WFM with

<form action="http://software.hixie.ch/utilities/cgi/test-tools/echo" method="post">
<textarea cols="30" rows="4" name="user_value92">500 000,00 &#8364; </textarea>
<input type="hidden" value="500 000,00 &#8364; " name="template_value92"/>
<input type=submit>
</form>

The behavior probably depends on the page's character encoding.  Can you reproduce the bug using the code I pasted but the encoding used by your site?
First thanks for your instant reply, awesome. Here is part of the reply from the echo script of yours:
CONTENT_TYPE = application/x-www-form-urlencoded
HTTP_ACCEPT_CHARSET = ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_ACCEPT_LANGUAGE = fi,en;q=0.5
HTTP_USER_AGENT = Mozilla/5.0 (Windows; U; Windows NT 5.1; fi; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Content
=======
forwardLink=
&user_value92=500+000%2C00+%80+&template_value92=500+000%2C00%A0%80%A0&

And here is the header of the form page:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="" xml:lang="fi" lang="fi">

Where does "forwardLink" come from?

Is the %A0 the problem?  %A0 is a non-breaking-space character in some encodings; I wonder where it's coming from.

I can't reproduce the bug.  What charset is the form page in?
Assignee: nobody → form-submission
Component: Form Manager → HTML: Form Submission
Product: Firefox → Core
QA Contact: form.manager → ian
Version: unspecified → 1.8 Branch
The echo script is hixie's, not mine ;)
If the original has non-breaking spaces, maybe you're hitting bug 218277.
Jesse, you are right. I browsed through the bug 218277 and now I have to declare, that FF cannot be used with our system because of this nbsb to regular (160 -> 20) issue. We have to recommend IE, which I personally would not like to use, sad. IMHO, FF should behave exactly as IE does about this matter.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 218277
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.