Bug 14562 – [Win] Textarea contents partially eaten on submit/copy

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Matt Lilek]

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.

[Mark Rowe (bdash)]

This sounds similar to another issue with submitted text area data being truncated when containing non-ASCII characters.

[Cameo Wood]

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. 

[Charles Gaudette]

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. 

[David Kilzer (:ddkilzer)]

<rdar://problem/5323808>

[frank goossens]

similar to http://bugs.webkit.org/show_bug.cgi?id=14165

[David Kilzer (:ddkilzer)]

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!

[frank goossens]

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 ...

[David Kilzer (:ddkilzer)]

(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?

[David Kilzer (:ddkilzer)]

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.)

[frank goossens]

(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

[Matt Lilek]

This involves data loss, bumping to P1

[frank goossens]

*** Bug 14165 has been marked as a duplicate of this bug. ***

[Michael Doppler]

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.

[frank goossens]

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.

[Matt Lilek]

*** Bug 14922 has been marked as a duplicate of this bug. ***

[Benoit Bolduc]

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.

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.

(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.

[David Kilzer (:ddkilzer)]

*** Bug 15075 has been marked as a duplicate of this bug. ***

[David Jaša]

From bug 15075: this bug is triggered by some czech accented characters: (пќту), while other (мљишћэбнйъщ) are safe.

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.

[David Jaša]

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

[Oliver Hunt]

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.

[Oliver Hunt]

<rdar://problem/5269732> (original radar closed as a dupe of this one)

(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.

[Oliver Hunt]

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

[David Jaša]

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.

[Oliver Hunt]

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

[Oliver Hunt]

Sending        win/ChangeLog
Sending        win/WebView.cpp
Transmitting file data ..
Committed revision 25251.

[Robert Blaut]

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.

[David Jaša]

I tested it on nightly build 25255 and problem seems gone. Neither dead-keys nor AltGr+some_key characters add empty character.

[David Kilzer (:ddkilzer)]

(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!

[David Kilzer (:ddkilzer)]

*** Bug 14179 has been marked as a duplicate of this bug. ***