350073 - Bidi: Word deletion happens immediately even if the caret is not adjacent to the deleted word

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Uri Bernstein]

In bidi text, when backspace is pressed, and the caret is not next to the character logically before the insertion point (i.e., the character to be deleted), then no deletion happens, but the caret moves visually to the position after the character to be deleted. The same is true for "del". This is done in order not to unexpectedly delete a character which the user did not mean to delete.

However, when instead of "backspace" and "del", ctrl+backspace or ctrl+del is used to delete a whole word, the word is deleted immediately. Instead, the caret should be moved as in the "delete character" cases, and no deletion should happen.

Testcase coming up

Comment 1

[Uri Bernstein]

Attachment: testcase

With the included instructions, this testcase should work for either setting of layout.word_select.eat_space_to_next_word.

Comment 2

[Simon Montagu :smontagu]

Just a note on WIP here: I had hoped that this would be as simple as moving http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/editor/libeditor/text/nsTextEditRules.cpp&rev=1.204&mark=916-919#903 outside the |if (bCollapsed) {}| (and the equivalent in nsHTMLEditRules.cpp) but there are problems: CheckBidiLevelForDeletion() finds the direction of the deletion by testing (nsIEditor::eNext==aAction), but for word deletion aAction is set to nsIEditor::eNone in nsPlainTextEditor::DeleteSelection()

Comment 3

[Uri Bernstein]

Another problem is that extending the selection affects the caret bidi level (nsFrameSelection::MoveCaret() calls SetCaretBidiLevel()) - and this throws off the tests in CheckBidiLevelForDeletion().