[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





--- Comment #7 from Ryosuke Niwa <rniwa at webkit.org>  2011-01-19 10:24:26 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > 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.
> 
> I am sorry, I simply do not understand what this means. I guess I don’t understand what you mean by “edge”.

Sorry, I'm failing in explaining what's happening.

> > 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
> 
> Doesn’t this mean that WebKit paints the insertion point on the left when the selection is at 0?

Yes, or more precisely, puts the insertion point and the caret on the left.

> > On Internet Explorer and Firefox, the caret moves from right to left all the way.
> 
> Doesn’t this mean that Internet Explorer paints the insertion point on the right when the selection is at 0?

Yes, and ditto.

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