113001 2013-03-21 21:40:48 -0700 Some Hebrew diacritics get messed up on form submission 2013-07-31 09:46:15 -0700 1 1 1 Unclassified WebKit Forms 528+ (Nightly build) All All RESOLVED INVALID http://zapad.org/~ignatiev/temp/w4.php P3 Normal --- 0 ikn webkit-unassigned ap rniwa oldest_to_newest 861082 0 194439 ikn 2013-03-21 21:40:48 -0700 Created attachment 194439 Source of PHP script to reproduce the problem When I submit any form which has a text field which contains Hebrew diacritics U+05BC ("dagesh") and U+05B6 ("segol"), in this order, they get submitted to the server in the *opposite* order: U+05B6, U+05BC . While Hebrew word seems "same" visually, this "fixed" order is invalid (or at least non-standard), and regardless, browser obviously shouldn't change data entered into the form on its own, under any circumstances. To demonstrate this issue, I wrote a simple PHP script (attached, and available online at http://zapad.org/~ignatiev/temp/w4.php), which allows user to fill a text field and then upon form submission to compare user input with what was actually submitted (via simple hash sum JavaScript implementation). You can play with it and see that it works fine for almost any text in any language you can enter. If, however, you use button "initialize", script will initialize the text field to the string '\u05d1\u05bc\u05b5' (bet-dagesh-segol), and upon form submission the comparison test will FAIL; value submitted will be '\u05d1\u05b5\u05bc' bet-segol-dagesh. This problem is reproducible in any WebKit-based browser I tried (Chrome Windows/Mac, Safari Mac/Windows/iPhone, Debian 6 "Web browser", also on the latest "nightly build", compiled from source on Linux/GTK), while it works fine in IE, Firefox, and (Presto-based) Opera. 863884 1 ap 2013-03-26 11:58:08 -0700 > this "fixed" order is invalid (or at least non-standard) In fact, '\u05d1\u05bc\u05b5' is not properly normalized - both NFC and NFD forms for this string are '\u05d1\u05b5\u05bc'. Please see <http://unicode.org/reports/tr15/> for discussion of Unicode normalization forms. Overall, this is expected behavior. The reason why we normalize to NFC when sending for text is compatibility - since Windows uses NFC everywhere, there can be subtle errors when the text sent from WebKit gets processed by systems that don't work with decomposed text well. I can see how in this specific case WebKit becomes an outlier, but this is the cost of being like other browsers in more common cases. 913387 2 ap 2013-07-31 09:46:15 -0700 *** Bug 119320 has been marked as a duplicate of this bug. *** 194439 2013-03-21 21:40:48 -0700 2013-03-21 21:40:48 -0700 Source of PHP script to reproduce the problem w4.php text/html 1683 ikn PCFET0NUWVBFIGh0bWw+CjxodG1sPgogIDxoZWFkPgogICAgPG1ldGEgY29udGVudD0idGV4dC9o dG1sOyBDSEFSU0VUPVVURi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIC8+CiAgICA8dGl0 bGU+Rm9ybSBzdWJtaXNzaW9uIHRlc3Q8L3RpdGxlPiAgCiAgPC9oZWFkPgogIDxib2R5IHN0eWxl PSJkaXJlY3Rpb246IGx0cjsiPgogICAgPGZvcm0gbmFtZT0ibWFpbmZvcm0iIGFjdGlvbj0iPD89 QCRfU0VSVkVSWydTQ1JJUFRfTkFNRSddOz8+IiAKCSAgbWV0aG9kPSJnZXQiIG9uc3VibWl0PSJy ZXR1cm4gb25zdWIoKTsiPgogICAgICA8ZGl2PklucHV0IGZpZWxkOgoJPGlucHV0IHR5cGU9InRl eHQiIG5hbWU9InYiIG1heGxlbmd0aD0iNTAiIHZhbHVlPSI8Pz1AJF9HRVRbJ3YnXTs/PiI+Cgk8 aW5wdXQgdHlwZT0iYnV0dG9uIiB2YWx1ZT0iJmx0Oz09IGluaXRpYWxpemUiIG9uY2xpY2s9ImNv cHkoKSI+CiAgICAgIDwvZGl2PgogICAgICA8ZGl2PgoJPGlucHV0IHR5cGU9InN1Ym1pdCIgbmFt ZT0iZm9ybVN1Ym1pdCIgdmFsdWU9IlRlc3QgY3VycmVudCB3b3JkIj4KCVJlc3VsdDogPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXNpemU6IGxhcmdlOyIgaWQ9ImNvbXByZXMi Pj8/Pzwvc3Bhbj4KICAgICAgPC9kaXY+CiAgICAgIDxpbnB1dCBuYW1lPSJoYXNoIiB0eXBlPSJo aWRkZW4iIHZhbHVlPSI8Pz1AJF9HRVRbJ2hhc2gnXTs/PiI+CiAgICA8L2Zvcm0+CiAgICA8c2Ny aXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+ClN0cmluZy5wcm90b3R5cGUuaGFzaENvZGUgPSBm dW5jdGlvbigpewoJdmFyIGhhc2ggPSAwOwoJaWYgKHRoaXMubGVuZ3RoID09IDApIHJldHVybiBo YXNoOwoJZm9yIChpID0gMDsgaSA8IHRoaXMubGVuZ3RoOyBpKyspIHsKCQljaGFyID0gdGhpcy5j aGFyQ29kZUF0KGkpOwoJCWhhc2ggPSAoKGhhc2g8PDUpLWhhc2gpK2NoYXI7CgkJaGFzaCA9IGhh c2ggJiBoYXNoOyAvLyBDb252ZXJ0IHRvIDMyYml0IGludGVnZXIKCX0KCXJldHVybiBoYXNoOwp9 CnZhciBlID0gZG9jdW1lbnQuZm9ybXMubWFpbmZvcm0uZWxlbWVudHMudjsKdmFyIGggPSBkb2N1 bWVudC5mb3Jtcy5tYWluZm9ybS5lbGVtZW50cy5oYXNoOwp2YXIgcyA9ICdcdTA1ZDFcdTA1YmNc dTA1YjUnOwpmdW5jdGlvbiBjb3B5ICgpIHsKICBlLnZhbHVlID0gczsKfQpmdW5jdGlvbiBjb21w YXJlICgpIHsKICB2YXIgYyA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdjb21wcmVzJyk7CiAg aWYgKGUudmFsdWUuaGFzaENvZGUgKCkudG9TdHJpbmcgKCkgPT0gaC52YWx1ZSkgewogICAgYy5p bm5lckhUTUwgPSAiUGFzcyI7CiAgICBjLnN0eWxlLmNvbG9yID0gImdyZWVuIjsKICB9CiAgZWxz ZSB7CiAgICBjLmlubmVySFRNTCA9ICJGQUlMIjsKICAgIGMuc3R5bGUuY29sb3IgPSAicmVkIjsK ICB9Cn0KZnVuY3Rpb24gb25zdWIgKCkgewogIGgudmFsdWUgPSBlLnZhbHVlLmhhc2hDb2RlICgp LnRvU3RyaW5nICgpOwogIHJldHVybiB0cnVlOwp9CmlmIChoLnZhbHVlKQogIGNvbXBhcmUgKCk7 CiAgICA8L3NjcmlwdD4KICAgIDxkaXYgc3R5bGU9J2ZvbnQtc2l6ZTogc21hbGw7IGNvbG9yOiBn cmF5Jz4KICAgICAgPGhyPgogICAgICA8Pz1AJF9TRVJWRVJbJ0hUVFBfVVNFUl9BR0VOVCddOz8+ CiAgICA8L2Rpdj4KICA8L2JvZHk+CjwvaHRtbD4K