Bug 60867 - [test case] corrupted data when submitting <option> fields with &nbsp; characters
Summary: [test case] corrupted data when submitting <option> fields with &nbsp; charac...
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml forms (show other bugs)
Version: 3.1
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-07 11:33 UTC by avi
Modified: 2010-03-14 18:42 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
testcase (171 bytes, text/html)
2008-04-06 06:00 UTC, George Goldberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description avi 2003-07-07 11:33:24 UTC
Version:            (using KDE KDE 3.1)
Installed from:    Unspecified Linux
Compiler:          gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) 
OS:          Linux

This is related to bug 40588, but I beleive it is a different bug, not a duplicate.

Bug 40588 mentions that &nbsp; sequences are reperesented as ascii 0xa0. Which may or may not be rendered correctly (incorrectly in my particular case :).

There is a more serious problem however - apparently the characters are submitted incorrectly to the web server. At least ClearQuest web from IBM gets confused.
Comment 1 avi 2003-07-07 11:50:49 UTC
Ok. The following html:

<html>
<body>
<form method=get>
<select name=a>
<option selected>a&nbsp;&nbsp;&nbsp;&nbsp;v</option>
</select>
<input type=submit>
</form>

Produces, in Netscape 4 (which works with ClearQuest quite will), the following:
GET request: file:/users2/avi/form.html?a=a%A0%A0%A0%A0v

In Knoqueror, this is what I get:

file:/users2/avi/form.html?a=a+v

Mozilla's even worse:

file:///users2/avi/form.html?a=a%C2%A0%C2%A0%C2%A0%C2%A0v
Comment 2 Thiago Macieira 2003-07-07 16:54:01 UTC
Confirmed for Konqueror from CVS HEAD. What I don't know is what is really expected. I 
believe the Netscape/Mozilla behaviour is the correct one. 
 
&nbsp; should be mapped to the Unicode Non-Breaking Space U+00A0, which encoded in 
Latin 1 is %A0 and encoded in UTF-8 is %C2%A0. By the way, your "worse" behaviour for 
Mozilla happened because you had the page's charset to UTF-8.  
Comment 3 avi 2003-07-07 17:04:10 UTC
Actually Knoqueror does NOT confuse ClearQuest -- I got mixed up in my testing.
The only problem is rendering, which is, of course, a duplicate of bug 40588.

To summarize:
- Netscape 4.x generates %A0, the correct Latin-1 encoding, which works well
with ClearQuest.
- Mozilla 1.x generates %C2A0, the correct UTF-8 encoding, which does not. This
is probably due to a bug in ClearQuest or its web server.
- Konqueuror misrenders the characters, and generates nothing, but works with
ClearQuest.

So, while this could probably be classified as a bug, fixing it would mean that
I couldn't use Konqueror with ClearQuest :(

Sorry for the confusion.
Comment 4 Thiago Macieira 2003-07-07 17:18:52 UTC
Not really. The Netscape and Mozilla behaviour are the same and, seemingly, the 
correct one. Konqueror would be brought to that behaviour and would send %A0 
if the page is in Latin 1 or %C2%A0 if it's in UTF-8. 
 
So, assuming Mozilla's setting to UTF-8 was erroneous, Konqueror would then 
behave like Netscape and send %A0. 
Comment 5 avi 2003-07-07 17:25:11 UTC
Okay, thanks. KDE rocks.
Comment 6 Thiago Macieira 2003-11-17 17:23:07 UTC
Still present. Konqueror replaces the series of NBSP with one single breaking space, which then gets replaced by + in the encoded URL.
Comment 7 Tommi Tervo 2005-08-19 13:33:38 UTC
Still broken. r449681
Comment 8 George Goldberg 2008-04-06 06:00:59 UTC
Created attachment 24222 [details]
testcase

Still broken in svn trunk r793457.

Uploaded testcase.
Comment 9 Raphael Kubo da Costa 2010-03-14 18:40:04 UTC
SVN commit 1103252 by rkcosta:

Do not strip of simplify an <option>'s value.

Simplifying is simply wrong, and trimming isn't required by the spec,
so we just follow other engines' behaviour here.

BUG: 60867


 M  +2 -2      html_formimpl.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1103252
Comment 10 Raphael Kubo da Costa 2010-03-14 18:42:50 UTC
SVN commit 1103253 by rkcosta:

Backport r1103252.

Do not strip of simplify an <option>'s value.

Simplifying is simply wrong, and trimming isn't required by the spec,
so we just follow other engines' behaviour here.

CCBUG: 60867


 M  +2 -2      html_formimpl.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1103253