Created attachment 194439 [details]
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.
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.
> 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.
*** Bug 119320 has been marked as a duplicate of this bug. ***