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 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.
Ok. The following html: <html> <body> <form method=get> <select name=a> <option selected>a 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
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. 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.
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.
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.
Okay, thanks. KDE rocks.
Still present. Konqueror replaces the series of NBSP with one single breaking space, which then gets replaced by + in the encoded URL.
Still broken. r449681
Created attachment 24222 [details] testcase Still broken in svn trunk r793457. Uploaded testcase.
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
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