[Webkit-unassigned] [Bug 25222] extending selection after change text directionality behaves differently for textarea and div element

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 15 16:28:00 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=25222





------- Comment #2 from xji at chromium.org  2009-04-15 16:28 PDT -------
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'?


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list