Bug 25222 – RTL: extending selection after change text directionality behaves differently for textarea and div element

• Status: NEW
• Component: HTML Editing

[Xiaomei Ji]

Steps to reproduce:
1. open the attached test case
2. repeat the following steps to the first line ('div') and 2nd line ('textarea') separately.
a). select word "two" by place cursor after 'o' and continuing press shift+left arrow.
b) change directionality to 'right-to-left' using context menu (while still selects word "two")
c) press shift+left arrow 

Results:
1. for 'div' element (the first line), selection became "two ", which extends the original selection to include the space between 'two' and 'three". 
2. for 'textarea' (the 2nd line), selection became 'wo', 't' in 'two' was un-selected.

[Xiaomei Ji]

Created attachment 29520 [details]
test case

[Xiaomei Ji]

The reason of such difference is inside Editor::setBaseWritingDirection(WritingDirection direction).

'textarea' was handled in the 'if' block. And the original selection's (base, extent) was not changed, stays as (7,4). So, continuing press shift+left arrow select the logically next character of position '4' (which un-select 't') in RTL environment

'div' was handled in the other path, and Editor::applyParagraphStyleToSelection() was called.
Following the call stack, Editor::applyParagraphStyle() --> EditCommand::apply() --> ApplyStyleCommand::doApply() --> ApplyStyleCommand::applyBlockStyle(),
the cmd's ending selection was updated at the last statement updateStartEnd().
cmd's ending selection is used as the new selection, its (base, extend) changed from (7, 4) to (4, 7). So, continuing press shift+left arrow select the logically next character of position 7 (the space between 'two' and 'three') in RTL environment.


Both FF and IE handle the above extending selection after changing directionality the same way for 'div' and 'textarea'. They both un-select 't' in  both 'div' and 'textarea'. 

My question is:
1. Is the webkit handling difference by intention? or it is a bug?
2. If it is by intention, why? why 'textarea' and 'input type' are  handled differently than 'div'?

[Xiaomei Ji]

in Chromium bug:
http://code.google.com/p/chromium/issues/detail?id=9842

[Xiaomei Ji]

marked the bug as "resolved" by mistake. Reopen....

[Levi Weintraub]

> My question is:
> 1. Is the webkit handling difference by intention? or it is a bug?
> 2. If it is by intention, why? why 'textarea' and 'input type' are  handled differently than 'div'?

There was definitely a conscious decision made in r34935 to handle text inputs differently, but it seems inconsistent that the function changes the writing direction for all contents of the textarea, but only acts paragraph-level for the div.

If we want the difference in behavior I just mentioned but want consistent selection behavior, we can explicitly update the selection in the special case for text inputs, but it seems hacky.

[Xiaomei Ji]

(In reply to comment #5)
> > My question is:
> > 1. Is the webkit handling difference by intention? or it is a bug?
> > 2. If it is by intention, why? why 'textarea' and 'input type' are  handled differently than 'div'?
> 
> There was definitely a conscious decision made in r34935 to handle text inputs differently, but it seems inconsistent that the function changes the writing direction for all contents of the textarea, but only acts paragraph-level for the div.
> 
> If we want the difference in behavior I just mentioned but want consistent selection behavior, we can explicitly update the selection in the special case for text inputs, but it seems hacky.


Feedback from Uri who's been a go-to person of RTL editing in Mozilla:
"Behavior on text area is correct, behavior on div is incorrect.", from which I imply that the behavior of textarea and div on this matter should be consistent.

[Yair Yogev]

I expect a rich editing box to act like a word document - "only acts paragraph-level", not like a textarea - that should change the writing direction for all content.

Will changing the behavior for divs affect the behavior for rich editing (in Gmail for example)?
if it will, then it should not be changed IMO.
if not, then i don't have a strong opinion in this matter- while I see the paragraph-level behavior as superior, and generally a good thing... being consistent with FF/IE is also good.

btw if you test Firefox with the test case above, and press Ctrl+Shift+X while the div has focus (won't work the other way around), you will find that it changes the direction in the textarea too! that makes no sense... only FF does that

[Levi Weintraub]

(In reply to comment #7)
> I expect a rich editing box to act like a word document - "only acts paragraph-level", not like a textarea - that should change the writing direction for all content.
> 
> Will changing the behavior for divs affect the behavior for rich editing (in Gmail for example)?
> if it will, then it should not be changed IMO.
> if not, then i don't have a strong opinion in this matter- while I see the paragraph-level behavior as superior, and generally a good thing... being consistent with FF/IE is also good.

It would, and you're right.

I now think the issue here lies with the current editing command behavior of only preserving the start/end positions, and not the base/extent positions. It would be a large change to update them all to support this, and it may make sense to roll this into a larger reworking of how editing commands deal with selection preservation.