52176 2011-01-10 15:56:01 -0800 DOM position at the boundary of LTR/RTL text inside a RTL/LTR block is wrong 2011-01-19 11:35:02 -0800 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) All All RESOLVED INVALID P2 Normal --- 1 rniwa webkit-unassigned mitz playmobil xji oldest_to_newest 332018 0 rniwa 2011-01-10 15:56:01 -0800 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) 332080 1 78481 rniwa 2011-01-10 17:51:18 -0800 Created attachment 78481 demo 336395 2 mitz 2011-01-19 01:41:23 -0800 What do you mean by “the offset at the boundary of text”? An offset corresponding to that caret position? 336556 3 rniwa 2011-01-19 08:48:12 -0800 (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. 336564 4 mitz 2011-01-19 09:00:59 -0800 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). 336596 5 79442 rniwa 2011-01-19 09:58:56 -0800 Created attachment 79442 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. 336606 6 mitz 2011-01-19 10:13:50 -0800 (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? 336611 7 rniwa 2011-01-19 10:24:26 -0800 (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. 336615 8 mitz 2011-01-19 10:28:41 -0800 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. 336619 9 mitz 2011-01-19 10:33:02 -0800 (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. 336673 10 rniwa 2011-01-19 11:35:02 -0800 (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. 78481 2011-01-10 17:51:18 -0800 2011-01-19 09:58:56 -0800 demo rtl-in-ltr.html text/html 1160 rniwa PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1U eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPgo8L2hlYWQ+Cjxib2R5Pgo8 cD5UaGlzIHRlc3RzIGNhcmV0IHJlbmRlcmluZyBmb3IgYXJhYmljIG51bWVyYWwgaW4gYSBMVFIg YmxvY2suPC9wPgo8ZGl2IGlkPSJ0ZXN0IiBkaXI9Imx0ciIgb25tb3VzZXVwPSJsb2coKSIgb25r ZXl1cD0ibG9nKCkiIGNvbnRlbnRlZGl0YWJsZT7YsdizPC9kaXY+CjxwcmUgaWQ9ImxvZyI+PC9w cmU+CjxzY3JpcHQ+Cgp2YXIgdGVzdCA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCd0ZXN0Jyk7 CnZhciBzZWxlY3Rpb24gPSB3aW5kb3cuZ2V0U2VsZWN0aW9uKCk7CnRlc3QuZm9jdXMoKTsKCmZ1 bmN0aW9uIG1vdmVDYXJldChvZmZzZXQpIHsKICAgIHZhciByYW5nZSA9IGRvY3VtZW50LmNyZWF0 ZVJhbmdlKCk7CiAgICBzZWxlY3Rpb24ucmVtb3ZlQWxsUmFuZ2VzKCk7CiAgICByYW5nZS5zZXRT dGFydCh0ZXN0LmZpcnN0Q2hpbGQsIG9mZnNldCk7CiAgICByYW5nZS5zZXRFbmQodGVzdC5maXJz dENoaWxkLCBvZmZzZXQpOwogICAgc2VsZWN0aW9uLmFkZFJhbmdlKHJhbmdlKTsKICAgIGxvZygp Owp9CgpzZXRUaW1lb3V0KGZ1bmN0aW9uKCkge21vdmVDYXJldCgwKTt9LCAwKTsKc2V0VGltZW91 dChmdW5jdGlvbigpIHttb3ZlQ2FyZXQoMSk7fSwgMTAwMCk7CnNldFRpbWVvdXQoZnVuY3Rpb24o KSB7bW92ZUNhcmV0KDIpO30sIDIwMDApOwpzZXRUaW1lb3V0KGZ1bmN0aW9uKCkge21vdmVDYXJl dCgzKTt9LCAzMDAwKTsKc2V0VGltZW91dChmdW5jdGlvbigpIHttb3ZlQ2FyZXQoNCk7fSwgNDAw MCk7CgpmdW5jdGlvbiBsb2coKSB7CiAgICBpZiAoc2VsZWN0aW9uLmlzQ29sbGFwc2VkKQogICAg ICAgIHJlc3VsdCA9IHNlbGVjdGlvbi5nZXRSYW5nZUF0KDApLnN0YXJ0T2Zmc2V0OwogICAgZWxz ZQogICAgICAgIHJlc3VsdCA9IHNlbGVjdGlvbi5nZXRSYW5nZUF0KDApLnN0YXJ0T2Zmc2V0ICsg JywgJyArIHNlbGVjdGlvbi5nZXRSYW5nZUF0KDApLmVuZE9mZnNldDsKICAgIGRvY3VtZW50Lmdl dEVsZW1lbnRCeUlkKCdsb2cnKS5pbm5lckhUTUwgKz0gcmVzdWx0ICsgJ1xuJzsKfQoKPC9zY3Jp cHQ+CjwvYm9keT4KPC9odG1sPgo= 79442 2011-01-19 09:58:56 -0800 2011-01-19 09:58:56 -0800 demo bug52176.html text/html 1163 rniwa PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1U eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPgo8L2hlYWQ+Cjxib2R5Pgo8 cD5UaGlzIHRlc3RzIGNhcmV0IHJlbmRlcmluZyBmb3IgYXJhYmljIG51bWVyYWwgaW4gYSBMVFIg YmxvY2suPC9wPgo8ZGl2IGlkPSJ0ZXN0IiBkaXI9Imx0ciIgb25tb3VzZXVwPSJsb2coKSIgb25r ZXl1cD0ibG9nKCkiIGNvbnRlbnRlZGl0YWJsZT7Xntec16jXojwvZGl2Pgo8cHJlIGlkPSJsb2ci PjwvcHJlPgo8c2NyaXB0PgoKdmFyIHRlc3QgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgndGVz dCcpOwp2YXIgc2VsZWN0aW9uID0gd2luZG93LmdldFNlbGVjdGlvbigpOwp0ZXN0LmZvY3VzKCk7 CgpmdW5jdGlvbiBtb3ZlQ2FyZXQob2Zmc2V0KSB7CiAgICB2YXIgcmFuZ2UgPSBkb2N1bWVudC5j cmVhdGVSYW5nZSgpOwogICAgc2VsZWN0aW9uLnJlbW92ZUFsbFJhbmdlcygpOwogICAgcmFuZ2Uu c2V0U3RhcnQodGVzdC5maXJzdENoaWxkLCBvZmZzZXQpOwogICAgcmFuZ2Uuc2V0RW5kKHRlc3Qu Zmlyc3RDaGlsZCwgb2Zmc2V0KTsKICAgIHNlbGVjdGlvbi5hZGRSYW5nZShyYW5nZSk7CiAgICBs b2coKTsKfQoKc2V0VGltZW91dChmdW5jdGlvbigpIHttb3ZlQ2FyZXQoMCk7fSwgMCk7CnNldFRp bWVvdXQoZnVuY3Rpb24oKSB7bW92ZUNhcmV0KDEpO30sIDEwMDApOwpzZXRUaW1lb3V0KGZ1bmN0 aW9uKCkge21vdmVDYXJldCgyKTt9LCAyMDAwKTsKc2V0VGltZW91dChmdW5jdGlvbigpIHttb3Zl Q2FyZXQoMyk7fSwgMzAwMCk7CnNldFRpbWVvdXQoZnVuY3Rpb24oKSB7bW92ZUNhcmV0KDQpO30s IDQwMDApOwoKZnVuY3Rpb24gbG9nKCkgewogICAgaWYgKHNlbGVjdGlvbi5pc0NvbGxhcHNlZCkK ICAgICAgICByZXN1bHQgPSBzZWxlY3Rpb24uZ2V0UmFuZ2VBdCgwKS5zdGFydE9mZnNldDsKICAg IGVsc2UKICAgICAgICByZXN1bHQgPSBzZWxlY3Rpb24uZ2V0UmFuZ2VBdCgwKS5zdGFydE9mZnNl dCArICcsICcgKyBzZWxlY3Rpb24uZ2V0UmFuZ2VBdCgwKS5lbmRPZmZzZXQ7CiAgICBkb2N1bWVu dC5nZXRFbGVtZW50QnlJZCgnbG9nJykuaW5uZXJIVE1MICs9IHJlc3VsdCArICdcbic7Cn0KCjwv c2NyaXB0Pgo8L2JvZHk+CjwvaHRtbD4=