It's a bit different than the bug I filled for the Mac version, even if it may have the same cause. In the Windows version, it seems that it affects only textarea, I mean at least with testfields it works. And the bug behavior is a bit different, as when typing the international characters like "é" are well displayed, but when submiting, it subtmiting only the text until the first international character. For example, if I submit that text with Safari on Windows: "Les éléphants d'afrique aiment l'eau" the text submitted will be: "Les " This has been reproduced on Safari 3.01 official build, as well ws latest nightly build r23540.
<rdar://problem/5274075>
I presume this is fixed by removing/disabling Saft as well, like Bug 14178 Comment #7?
This bug deals with Safari on Windows, so I don't think Saft is relevant.
very similar to what i encountered, except i had the problem using '[[', ']]', '\\', ... see http://bugs.webkit.org/show_bug.cgi?id=14165
(In reply to comment #2) > I presume this is fixed by removing/disabling Saft as well, like Bug 14178 > Comment #7? > No in this case I use Safari for Windows without any addon/hack, and Saft doesn't exist on Windows anyway, and the bug is a bit different, the characters appears while I type, but the text typed isn't submitted correctly when submitting the form (see the description on my first comment). This bugs doesn't appear on Safari for Mac, it's a Windows version specific bug. It seems indeed similar (and may have the same cause) than what describe Frank.
cfr. bug 14165; changing keyboard layout to "US" instead of "dutch (belgian)" seems to make the bug disappear?
(In reply to comment #6) > cfr. bug 14165; changing keyboard layout to "US" instead of "dutch (belgian)" > seems to make the bug disappear? > With the latest nightly build, I can't even try to enter an é, this make Safari crash literally. This being with an US keyboard layout or not.
I can confirm that the textarea content is only submitted up to the first accented character or square bracket, on a Windows XP with Spanish localization. Not only that, on realizing that I was about to loose a blog entry that I was editing in Safari, I hit back and tried to copy the text to paste it into a local text editor. The clipboard content, however, only got pasted again up to the first accented character or square bracket, so I had to copy the text in blocks avoiding the special characters.
(In reply to comment #7) > With the latest nightly build, I can't even try to enter an é, this make Safari > crash literally. This being with an US keyboard layout or not. Could you please describe how you are typing the é character? I've tried copying it from Character Map application, and it seems to work fine. OTOH, Alt+0233 doesn't produce any character for me. I'm testing at <http://babelfish.altavista.com>; U.S. English Windows XP with primary Russian locale.
(In reply to comment #9) > Could you please describe how you are typing the é character? I'm typing it using Command+E with the US layout. Or the appropriate keys for others layout. I will test the copy of the character from another app too ASAP and report the result to you. But it's still a very high handicap to not being able to enter it with the keyboard directly in the form :)
(In reply to comment #10) > I'm typing it using Command+E with the US layout. Or the appropriate keys for > others layout. > Ooops I just realize that it did work because I'm testing Safari with Parallels on MacOS X, it seems that I used the usual Option (Apple key) + E and that Parallels did the work. But of course it doesn't work on real Windows machine... But you can also reproduce the bug passing the layout to French (setting it on regional settings) and pressing the '2' key of your US keybaord (the '2' key that is above the letters, not the one in the numeric pad).
A little information, it seems that it doesn't crash everywhere, I tried on Babelfish, and it didn't make it crash, but still the submission was wrong (submit only the part before the first special character like é). It crash on the search field of Google.com for example, whenever you type a special character like é. Also I confirm indeed that pasting from another application (I used the Notepad) the special characters does work and they are submitted properly in that case. Even if using this techniques on the Google.com search field does still make Safari crash. All the above was tested with latest Nightly build of Webkit.
A little update, apparently the latest 3.0.2 updates fix the bug, so I guess it was anothe Kit issue
A little update in fact, it does work for textfield, but apparently not for textareas, here a demo: This text should be truncated: Hello I like Spain, and it's said in spanish: Me gusta España.
(In reply to comment #14) > This text should be truncated: Hello I like Spain, and it's said in spanish: Me > gusta España. Hmm in fact very strange, it worked... While in babelfish typing the following (the end is "Les elephant aiment l'eau" with acute accent on the both e of elephant), didn't work: "At the end it seems that the latest updates didn't fix the problem entirely, I guess it was another Kit issue (CoreFoundation?). A little test to confirm that: Les
I still cannot properly reproduce this bug: everything works correctly with French layout in Windows and the "2" key, and Option+e simply opens Safari's Edit menu with my version of Parallels. However, I've found a way to produce bad input, at least under Parallels. With U.S. keyboard layout, I press Cmd+e (which opens a context menu), then Esc. This produces an invisible character, followed by e. Testing with Safari beta 3.0.2.
(In reply to comment #16) > I still cannot properly reproduce this bug: everything works correctly with > French layout in Windows and the "2" key I don't know what do you mean by everything works correctly, but I would like to remind you what is the bug and what is not: - The bug is not that the letters like é can't be typing, they indeed can be correctly (i.e: They appear on the textarea correctly) - The bug is limited to TestAreas (like the one used on this form to submit comments). - The bug is that the text after the special character like é, this character included. So for example if I type: "Les éléphants aiment l'eau", using french keyboard layout on a textarea like this one, after submission, the text will appear as: "Les ". Just try to type this sentence (Do not copy/paste it!) in a comment on this bug report: "Les éléphants aiment l'eau", using a french keyboard layout with the "2" key of your US keyboard. And then submit it, if your comment after submition appears as "Les ", is that you've reproduced the bug.
(In reply to comment #17) > - The bug is that the text after the special character like é, this character > included. > I meant: - The bug is that the text after the special character like é, this character included, is not submitted (the submitted text is only the part before the é character)
(In reply to comment #17) > I don't know what do you mean by everything works correctly, but I would like > to remind you what is the bug and what is not: <skipped> I do remember that, thanks. Clearly, this bug depends on some unknown-yet parameters (such as maybe the version of Parallels, Windows version and localization etc.). Thus, the alternative steps to reproduce I described in comment 16 might help to get it fixed.
(In reply to comment #19) > Clearly, this bug depends on some unknown-yet > parameters (such as maybe the version of Parallels, Windows version and > localization etc.). It seems that at least it has nothing to do with Parallels, as I've just seen a post on Apple discussion forum of someone having the same exact issue (typing portuguese words with accents), who is using a real PC (Athlon 64) but with its Windows XP in Portuguese. See here: http://discussions.apple.com/thread.jspa?threadID=1008179&tstart=0 And according to this site, this bug is also reported in <rdar://problem/5269732>
for those that are not testing nightly builds, this seems fixed (more info in http://bugs.webkit.org/show_bug.cgi?id=14562).
*** This bug has been marked as a duplicate of 14562 ***