Bug 52176 – DOM position at the boundary of LTR/RTL text inside a RTL/LTR block is wrong

• Status: RESOLVED
• Resolution: INVALID
• Component: HTML Editing

[Ryosuke Niwa]

In WebKit, the offset at the boundary of text follows the direction used by the surrounding text.

For example, abc (LTR) in a RTL block results in the offsets:
(3)a(1)b(2)c(0)
and CBA (RTL) in a LTR block results in the offsets:
(0)C(2)B(1)A(3)

But this is inconsistent with Firefox or MSIE both of which does:
(0)a(1)b(2)c(3)
(3)C(2)B(1)A(0)

[Ryosuke Niwa]

Created attachment 78481 [details]
demo

What do you mean by “the offset at the boundary of text”? An offset corresponding to that caret position?

[Ryosuke Niwa]

(In reply to comment #2)
> What do you mean by “the offset at the boundary of text”? An offset corresponding to that caret position?

Yes.  When the caret is at the either edge of LTR text in a RTL block or RTL text in a LTR block, the corresponding offset follows the block's text direction on WebKit whereas it follows text's direction on Internet Explorer and Firefox.

e.g. in a RTL block, when the caret is on the left of LTR text "abc", the offset is 3 on WebKit but 0 on Internet Explorer and Firefox.

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).

[Ryosuke Niwa]

Created attachment 79442 [details]
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.

(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”.


> 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?

> 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?

[Ryosuke Niwa]

(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.

I see. Like I said, this means that WebKit follows a certain convention for where to draw the insertion point when it’s at a directionality boundary, namely the Mac OS X text system convention. Other platforms may have other conventions. It might be good for WebKit ports to conform to the conventions of whatever platform they’re running on.

(In reply to comment #7)
> Yes, or more precisely, puts the insertion point and the caret on the left.

“Insertion point” (as I used it above) is just Mac OS X terminology for “caret”. I will stick to “caret” from now on.

[Ryosuke Niwa]

(In reply to comment #8)
> I see. Like I said, this means that WebKit follows a certain convention for where to draw the insertion point when it’s at a directionality boundary, namely the Mac OS X text system convention. Other platforms may have other conventions. It might be good for WebKit ports to conform to the conventions of whatever platform they’re running on.

(In reply to comment #9)
> (In reply to comment #7)
> > Yes, or more precisely, puts the insertion point and the caret on the left.
> 
> “Insertion point” (as I used it above) is just Mac OS X terminology for “caret”. I will stick to “caret” from now on.

I meant insertion point in the sense of where the text was inserted but I was clearly wrong.  Internet Explorer and Firefox use WebKit convention when text is inserted.

e.g. suppose we have מלרע in a LTR block, and run:

var range = document.createRange();
editor().focus();
range.setStart(editor().firstChild, 0);
range.setEnd(editor().firstChild, 0);
window.getSelection().removeAllRanges();
window.getSelection().addRange(range);

setTimeout(function() {document.execCommand("insertHTML", false, "hello");}, 1000);

where editor() is the LTR div that contains the text. Then the caret shows up on the right of מלרע momentarily, but moves to the left when the text is inserted. So in this regard, Firefox & Internet Explorer's behavior matches that of WebKit. In fact, their behavior is more confusing than WebKit's so maybe we should convince them to change the behavior.