Bug 14562 - [Win] Textarea contents partially eaten on submit/copy
Summary: [Win] Textarea contents partially eaten on submit/copy
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 523.x (Safari 3)
Hardware: PC Windows XP
: P1 Normal
Assignee: Nobody
URL:
Keywords: InRadar, NeedsReduction, PlatformOnly
: 14165 14179 14922 15075 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-07-08 12:10 PDT by Matt Lilek
Modified: 2007-08-27 07:35 PDT (History)
13 users (show)

See Also:


Attachments
Test page with textarea (102 bytes, text/html)
2007-07-14 14:18 PDT, David Kilzer (:ddkilzer)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Lilek 2007-07-08 12:10:56 PDT
I've seen this bug since the first Safari 3 Beta on Windows and continue to see it on ToT.  The contents of a texarea appears completely normal, editing perfectly fine - but when copied or submitted, the contents is partially (or mostly) cut off.  It appears to have something to do with undo/redo but I've not been able to pin it down exactly.
Comment 1 Mark Rowe (bdash) 2007-07-08 12:15:07 PDT
This sounds similar to another issue with submitted text area data being truncated when containing non-ASCII characters.
Comment 2 Cameo Wood 2007-07-08 14:45:59 PDT
hey guys- sorry I'm late to join this party.  

I've seen this when submitting text in a mediawiki.  I hit 'submit', the page submits nothing, and when I go back to resubmit, I cannot copy the information out of the text entry field at all.  

I have the text of what I was submitting, and it is reproducible on a mediawiki- I'll post it to this bug tomorrow when I get to my work computer. 
Comment 3 Charles Gaudette 2007-07-08 16:03:14 PDT
Just had this happen to me posting a bug from Win Safari (for the first time).

http://bugs.webkit.org/show_bug.cgi?id=14564

This may have happened when I copied a URL from Firefox's address bar to Safari's textarea.

Firefox v2.0.0.4; Safari 3.0.2 beta with r24089. 
Comment 4 David Kilzer (:ddkilzer) 2007-07-09 22:07:41 PDT
<rdar://problem/5323808>
Comment 5 frank goossens 2007-07-10 09:03:23 PDT
similar to http://bugs.webkit.org/show_bug.cgi?id=14165
Comment 6 David Kilzer (:ddkilzer) 2007-07-11 16:25:55 PDT
Reproducible steps would go a long way towards getting this bug fixed.  If anyone can reproduce this issue reliably, please post detailed step-by-step instructions.  Thanks!

Comment 7 frank goossens 2007-07-12 13:16:30 PDT
i can reproduce it each and every time, although that does not seem to be the case for most people out there. anyways;

1. open up site with a submit form that contains a textarea
2. add content that includes e.g. double square brackets (wiki code)
3. submit

result -> everything in the textarea from the double square brackets onwards is not submitted, but gets lost somehow. it really is as simple as that in my case ... :(

further tests seem to indicate that the problem might be related to the choosen language (regional and language options in control panel); when i switch my
keyboard from "dutch (belgian)" to "us" and restart safari, the bug does not
reproduce, when i switch back to "dutch (belgian)" the bug is back.

as difficult as it is to reproduce this bug, this is a major problem for what seems to be a minority of win-safari users (testers). hope you guys can crack this ...
Comment 8 David Kilzer (:ddkilzer) 2007-07-14 14:16:19 PDT
(In reply to comment #7)
> i can reproduce it each and every time, although that does not seem to be the
> case for most people out there. anyways;
> 
> 1. open up site with a submit form that contains a textarea
> 2. add content that includes e.g. double square brackets (wiki code)
> 3. submit

Thanks, Frank!!  Could you provide a specific URL (web page) that had such a form, and the exact contents of what you typed in the textarea?
Comment 9 David Kilzer (:ddkilzer) 2007-07-14 14:18:13 PDT
Created attachment 15520 [details]
Test page with textarea

For example, using this test page, exactly what do you type into it to make the contents truncated?  (The truncation will appear on the URL submitted since this is a method="get" form.)
Comment 10 frank goossens 2007-07-15 01:10:22 PDT
(In reply to comment #9)
> Created an attachment (id=15520) [edit]
> Test page with textarea
> 
> For example, using this test page, exactly what do you type into it to make the
> contents truncated?  (The truncation will appear on the URL submitted since
> this is a method="get" form.)
> 

text in textarea (copy/ pasting this form safari didn't work either btw):
"testing with some normal content
and adding some square brackets on the next line
[[test]]
and continuing with normal text"

url after submit:
http://bugs.webkit.org/attachment.cgi?ta=testing+with+some+normal+content%0D%0Aand+adding+some+square+brackets+on+the+next+line%0D%0A

some system info:
safari v3.0.2, 522.13.1
running on winxp sp2
input language dutch (belgium), belgian (period)
not going through a proxy
Comment 11 Matt Lilek 2007-07-20 11:37:30 PDT
This involves data loss, bumping to P1
Comment 12 frank goossens 2007-07-23 07:07:28 PDT
*** Bug 14165 has been marked as a duplicate of this bug. ***
Comment 13 Michael Doppler 2007-07-26 05:03:21 PDT
I also experience this problem on Windows XP x64 SP2 with Safari Beta 3.0.2. It happens every time I use one of the characters "|", "@", "[", "]" in each text area input form field I tested. The text in the form is truncated immediately before the first occurrence of one of the characters mentioned in the POST request sent to the server. It is displayed correctly while editing it in the text field before posting it.
Comment 14 frank goossens 2007-07-31 03:18:38 PDT
just re-tried with latest nightly webkit-build (WebKit-r24749), but the problem still persists. feel free to contact me if you need extra info about my system or settings, i'm eager to see this showstopper fixed.
Comment 15 Matt Lilek 2007-08-09 14:40:05 PDT
*** Bug 14922 has been marked as a duplicate of this bug. ***
Comment 16 Benoit Bolduc 2007-08-12 05:09:45 PDT
Hello all,

I'm also having this problem, with french characters such as : ç à ò ì ù ç ô î û and so on...

The copy/paste seems to work fine though. It just happens when I'm actually typing in the characters in the textarea.

My two cents.
Comment 17 mitz 2007-08-18 02:23:25 PDT
I think this bug is at least partly related to bug 14941: FormDataList::appendString uses a C string, so the 0 byte acts as terminator. I have verified that the same happens with the Windows clipboard, but I have not looked up the code where it happens.
Comment 18 mitz 2007-08-18 03:01:10 PDT
(In reply to comment #17)
> I think this bug is at least partly related to bug 14941:
> FormDataList::appendString uses a C string, so the 0 byte acts as terminator.

Actually CStrings can contain 0 bytes, but fixLineBreaks doesn't know that. I will try to fix that first.
Comment 19 David Kilzer (:ddkilzer) 2007-08-25 06:48:48 PDT
*** Bug 15075 has been marked as a duplicate of this bug. ***
Comment 20 David Jaša 2007-08-25 07:13:47 PDT
From bug 15075: this bug is triggered by some czech accented characters: (пќту), while other (мљишћэбнйъщ) are safe.
Comment 21 mitz 2007-08-25 08:39:44 PDT
I tried to see how 0 bytes get in and I found that, for example, when you press the Insert key, WebView::handleEditingKeyboardEvent() calls insertText with text consisting of a 0 byte, because that key does not map to character and is not interpreted as a command (the arrow keys also have a singe 0 byte as their text, but because they have an interpretation as commands, they don't go through insertText). I don't know how the various accented characters are typed so I did not look into it.
Comment 22 David Jaša 2007-08-25 12:24:46 PDT
Note on accented characters: if they're typed directly, they're OK. But if you use "dead key" with accent followed by unaccented character key to type them, Safari eats it and the rest. If you want to delete character typed with dead key, you have to hit backspace/delete* key twice although there's no visual change.

* You have to move focus one character to left if you want to delete it with "delete" key
Comment 23 Oliver Hunt 2007-08-25 12:31:04 PDT
It is clear webkit/win is allowing control characters get into the text field -- eg aESCb <submit> in the attached testcase will result in ta=a%1Bb.

I'm currently tracking down why this does not happen in mac.  I suspect the control keys are mapped appropriately by the input method, so that webkit never sees the control characters.
Comment 24 Oliver Hunt 2007-08-25 12:31:49 PDT
<rdar://problem/5269732> (original radar closed as a dupe of this one)
Comment 25 mitz 2007-08-25 12:32:59 PDT
(In reply to comment #22)
> Note on accented characters: if they're typed directly, they're OK. But if you
> use "dead key" with accent followed by unaccented character key to type them,
> Safari eats it and the rest. If you want to delete character typed with dead
> key, you have to hit backspace/delete* key twice although there's no visual
> change.

That's consistent with the dead key inserting a 0-byte, same way the Insert key does it. Those keystrokes should definitely not end up calling insertText, but I don't know the code enough to say if handleEditingKeyboardEvent() is the right place to stop them.
Comment 26 Oliver Hunt 2007-08-25 14:48:15 PDT
Okay, have prevented the insertion of the null characters that certain keypresses will generate, still need to deal with control characters that should not get there.

Anyone know how to do dead key entry on windows? eg é, etc
Comment 27 David Jaša 2007-08-25 15:27:59 PDT
Oliver, go to Start -> Settings -> Control panel -> Regional and Language Options -> Languages tab -> Details button and in this dialog add Czech input language with Czech keyboard. First dead key is the same as =+ in us layout (typing ´ and ¡ accents) and second is \ key near Enter key, which types diaeresis ¨. You can switch layouts with alt + shift shortcut by default.
Comment 28 Oliver Hunt 2007-08-25 15:32:31 PDT
Cheers David, I'd got there through a belgian keyboard :D

I have a fix for the truncation, am currently working out how to handle invisible characters
Comment 29 Oliver Hunt 2007-08-25 19:23:19 PDT
Sending        win/ChangeLog
Sending        win/WebView.cpp
Transmitting file data ..
Committed revision 25251.
Comment 30 Robert Blaut 2007-08-27 04:55:30 PDT
Thank you for fixing this a really annoying bug. I can confirm that sending forms works fine now, but I noticed a new glitch which is probably related to this fix. I use alt + key combination to type Polish letters and currently pressing down alt key results in typing " " space char. This issue is absent in previous nightly r25237.
Comment 31 David Jaša 2007-08-27 07:22:07 PDT
I tested it on nightly build 25255 and problem seems gone. Neither dead-keys nor AltGr+some_key characters add empty character.
Comment 32 David Kilzer (:ddkilzer) 2007-08-27 07:33:11 PDT
(In reply to comment #30)
> Thank you for fixing this a really annoying bug. I can confirm that sending
> forms works fine now, but I noticed a new glitch which is probably related to
> this fix. I use alt + key combination to type Polish letters and currently
> pressing down alt key results in typing " " space char. This issue is absent in
> previous nightly r25237.

Please open a new bug for this issue.  Thanks!

Comment 33 David Kilzer (:ddkilzer) 2007-08-27 07:35:13 PDT
*** Bug 14179 has been marked as a duplicate of this bug. ***