Steps to reproduce: * Type a single Hebrew letter in an empty LTR text entry field. * Move the cursor so it's at the right of the letter. * Press the forward delete key. Expected result: * The letter should be deleted. Actual results: The delete key has no effect, moving the cursor to the left of the letter however and pressing delete removes the letter as if it where an LTR character. If the text entry field is rtl aligned the delete key works as expected. WebKit trunk's current behavior departs from that of FF, Safari 3.2 and IE.
I am confused because the bug's summary and the description seem to describe two different situations. As far as I can tell, WebKit behaves correctly. After typing a letter, forward-delete should never delete the just-typed letter.
In IE7 and FF if there is a single Hebrew letter in an LTR text input field and the caret is to the right of the letter, pressing the forward delete key deletes that letter. In Webkit trunk, if you type a single Hebrew letter in an LTR field the caret is positioned to the right of that letter so it makes sense that the delete key would have no effect however the behavior is confusing in that it departs from other browsers.
(In reply to comment #2) > In IE7 and FF if there is a single Hebrew letter in an LTR text input field and > the caret is to the right of the letter, pressing the forward delete key > deletes that letter. This does not seem to always be the case. To reproduce: 1. Open this page in Firefox 2. In the Additional Comments field, type a Hebrew letter 3a. Click inside the field, somewhere below the letter and to the right; or 3b. Press the down arrow key; or 3c. Press the space bar, then press the delete key 4. Note that the insertion point is now to the right of the Hebrew letter 5. Press the forward delete key In all three versions, the Hebrew letter will not be deleted. WebKit's behavior is consistent with the Cocoa text system in Mac OS X (however WebKit does not draw the secondary caret (bug 3710)), so I don't think this bug applies to the Mac OS X port. Even though there are only two possible caret selections in this case, Firefox seems to recognize three different modes, in two of which the insertion point is drawn to the right of the letter (yet they differ in the height of the caret); you can alternate between these modes by pressing the up and down arrow keys after step 3b above. I am not sure what platform convention Firefox is trying to emulate. Should WebKit allow three different caret selections in this case? What is the general principle to be followed?
Implementing a split caret would solve this as it would remove the confusion around whether your at the start or end of an rtl run. I'm closing this bug in favor of https://bugs.webkit.org/show_bug.cgi?id=3710 Thanks for your comments!