Looking at [1] it seems that directionality of empty editable element (particularly caret position) with dir=auto should fallback to parent's directionality (see attached testcase). But currently caret is always left aligned inside such elements. Although only textarea is mentioned at [1], probably the same should be applied to input and [contenteditable]. As Gaia::SMS app we're especially interested in fixing this for [contenteditable]. [1] https://html.spec.whatwg.org/multipage/dom.html#the-dir-attribute

> from bug 1080832 comment 18 Hey Ehsan, we need your advice here :) Let me describe the problem we're trying to solve: ──html[dir=rtl] │ └──div.recipients │ └──span.phone-or-contact-name-input[contenteditable=true][dir=auto] Here we have RTL document with [contenteditable=true] as input, it also has [dir=auto] to at least correctly format phone numbers in international format (eg. +1234). The problem here is that the caret is always LTR-oriented if [contenteditable=true][dir=auto] is empty. The first workaround we tried was to make [contenteditable] narrow enough (so that when it's empty only caret is displayed) and properly align it itself - everything works fine except that it's amolst not recongnizable by ScreenReader, so we have to make it as wide as possible. I've quickly skimmed through the spec [1] and found that at least for textareas we have the following statement: --------------------------- * If the element is a textarea element and the dir attribute is in the auto state ** If the element's value contains a character of bidirectional character type AL or R, and there is no character of bidirectional character type L anywhere before it in the element's value, then the directionality of the element is 'rtl'. ** Otherwise, if the element's value is not the empty string, or if the element is a root element, the directionality of the element is 'ltr'. ** Otherwise, the directionality of the element is the same as the element's parent element's directionality. --------------------------- So if I understand it correctly, then if textarea[dir=auto] is empty its direction (thus caret position) should be inherited from the parent (that is RTL in our case). Is the same rule valid for [contenteditable=true][dir=auto]/input[dir=auto]? [1] https://html.spec.whatwg.org/multipage/dom.html#the-dir-attribute

(In reply to Oleg Zasypkin [:azasypkin] from comment #0) > Created attachment 8526849 [details] > testcase.html > > Looking at [1] it seems that directionality of empty editable element > (particularly caret position) with dir=auto should fallback to parent's > directionality (see attached testcase). But currently caret is always left > aligned inside such elements. > > Although only textarea is mentioned at [1], probably the same should be > applied to input and [contenteditable]. > > As Gaia::SMS app we're especially interested in fixing this for > [contenteditable]. If you remove the <br/> from the contenteditable div in your testcase, leaving the element as <div contenteditable="true" dir="auto"></div> this seems to improve things; at least in a desktop Nightly build, it puts the caret initially at the right. One thing is still slightly odd: if I enter some LTR text, the contenteditable div gets dir=ltr (as expected), but then if I delete all the text, the caret remains on the left.

Simon, I think this is really one for you. I don't have much clue about the dir=auto implementation. Just as an experiment, I tried hacking SetDirectionalityFromValue to look at the ancestor's directionality if the element is empty. This seems to give the desired behavior for <input> elements, but I don't know if it may have undesirable side-effects; and it doesn't do anything for <textarea>.

(In reply to Jonathan Kew (:jfkthame) from comment #2) > (In reply to Oleg Zasypkin [:azasypkin] from comment #0) > One thing is still slightly odd: if I > enter some LTR text, the contenteditable div gets dir=ltr (as expected), but > then if I delete all the text, the caret remains on the left. That's probably because of the fact that we add <br> to contenteditable if its content was removed (eg. with Backspace key), see recently landed bug 1094000.

Experimenting further with the contenteditable example here, I've noticed that we fail to update the directionality properly if you replace the contents with neutral-dir text after doing a Select All. Filed bug 1103348 on that aspect.

FWIW this was added to the HTML spec relatively recently (in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17835), and we never updated the dir=auto implementation.

(In reply to Jonathan Kew (:jfkthame) from comment #3) > Created attachment 8527000 [details] [diff] [review] > part 1 - Try to inherit parent's directionality into empty <input > dir="auto"> element. > > Simon, I think this is really one for you. I don't have much clue about the > dir=auto implementation. Just as an experiment, I tried hacking > SetDirectionalityFromValue to look at the ancestor's directionality if the > element is empty. This seems to give the desired behavior for <input> > elements, but I don't know if it may have undesirable side-effects; and it > doesn't do anything for <textarea>. No, it wouldn't -- only <input>s use SetDirectionalityFromValue. <textareas> with dir=auto depend on the handling of NS_STYLE_UNICODE_BIDI_PLAINTEXT in nsBidiPresUtils.cpp. We could special-case empty elements there, but I gather from comment 2 and comment 4 that the problematic elements are not necessarily actually empty, which complicates matters.

(In reply to Simon Montagu :smontagu from comment #6) > FWIW this was added to the HTML spec relatively recently (in > https://www.w3.org/Bugs/Public/show_bug.cgi?id=17835), and we never updated > the dir=auto implementation. Yeah, we should update our implementation here.

Simon, is it something you could find the time to work on? This is really some polish issues but still polish issues are important for a consistent UX. Thanks a lot !

I still reproduce this in v2.5, except that it is a text-align issue, not a direction one. I can't reproduce with the attached example any more, so filling https://bugzilla.mozilla.org/show_bug.cgi?id=1212875 instead. There is a working test case attached.

[Step] - click on the "updated test case" attachment. - focus the contenteditable="true" element, ie the grey box at the end of the page - observe the caret position [Expected] - As this element has a `text-align="right"` the caret should be on the right. [Actual] - The caret is on the left, and jumps to the right as soon as we begin typing.