25222 2009-04-15 16:10:42 -0700 RTL: extending selection after change text directionality behaves differently for textarea and div element 2011-01-26 15:45:41 -0800 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) All All NEW P2 Normal --- 1 xji webkit-unassigned jparent jshin leviw mitz playmobil progame+wk rniwa xji oldest_to_newest 117688 0 xji 2009-04-15 16:10:42 -0700 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. 117689 1 29520 xji 2009-04-15 16:11:05 -0700 Created attachment 29520 test case 117692 2 xji 2009-04-15 16:28:00 -0700 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'? 117693 3 xji 2009-04-15 16:29:07 -0700 in Chromium bug: http://code.google.com/p/chromium/issues/detail?id=9842 214395 4 xji 2010-04-19 18:01:04 -0700 marked the bug as "resolved" by mistake. Reopen.... 340406 5 leviw 2011-01-26 12:35:14 -0800 > 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. 340417 6 xji 2011-01-26 12:50:05 -0800 (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. 340430 7 progame+wk 2011-01-26 13:18:57 -0800 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 340530 8 leviw 2011-01-26 15:45:41 -0800 (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. 29520 2009-04-15 16:11:05 -0700 2009-04-15 16:11:05 -0700 test case mouse_selection.htm text/html 340 xji PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPg0KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiID4NCjxo ZWFkPg0KICAgIDx0aXRsZT5VbnRpdGxlZCBQYWdlPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5Pg0K PGRpdiBjb250ZW50ZWRpdGFibGU+b25lIHR3byB0aHJlZTwvZGl2Pg0KPHRleHRhcmVhIGNvbnRl bnRlZGl0YWJsZT5vbmUgdHdvIHRocmVlPC90ZXh0YXJlYT4NCjwvYm9keT4NCjwvaHRtbD4NCg==