[Webkit-unassigned] [Bug 52176] DOM position at the boundary of LTR/RTL text inside a RTL/LTR block is wrong

[bugzilla-daemon at webkit.org]

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


Ryosuke Niwa <rniwa at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #78481|0                           |1
        is obsolete|                            |




--- Comment #5 from Ryosuke Niwa <rniwa at webkit.org>  2011-01-19 09:58:56 PST ---
Created an attachment (id=79442)
 --> (https://bugs.webkit.org/attachment.cgi?id=79442&action=review)
demo

(In reply to comment #4)
> I see. WebKit's positioning of the caret in these cases is apparently consistent with where the Cocoa and Carbon text systems in Mac OS X put the primary caret (or the only caret, when not using a split caret).

The actual rendering of caret is consistent with Internet Explorer and Firefox. It's the DOM offset we expose to JavaScript that's off. i.e. we're using an offset different from IE/FF to mean edges of LTR/RTL text in a RTL/LTR block.

Open the attachment, this demo slowly increments the DOM offset from 0 to 4.  If you open it on WebKit, it starts on the left edge, then moves to the second offset from the right, and then keeps moving to the left until the second offset from the left, and the jumps back to the right edge.  On Internet Explorer and Firefox, the caret moves from right to left all the way.

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