The position of the resizer in RTL textareas should be on the bottom left, but it's on the bottom right right now. See the URL field for a sample.

It should be appearing on the same side as the scrollbar, yet the scrollbar side is controlled by the preference layout.scrollbar.side instead.

(In reply to comment #1) > It should be appearing on the same side as the scrollbar, yet the scrollbar > side is controlled by the preference layout.scrollbar.side instead. Hmm, ok, but it doesn't make a lot of sense for it to appear on the right side. It is weird (the resizer on everything else, for example windows, appears on the bottom left side); its visual direction points to south west, its interaction is RTL (dragging the cursor to left makes the textarea bigger) and worse than all, it will overlay text inside the textarea: data:text/html;charset=utf8,<textarea dir=rtl cols=20 rows=2>از مرورگری استفاده کنید که به زبان شما صحبت می‌کند!</textarea> If we're going to leave it at that side, we should make sure that it is visually identical to LTR resizers, and it doesn't overlap the text in any case.

I think that the preference layout.scrollbar.side should only apply to the top-level window, but widgets within a page should always position the scrollbar according to the direction of the element. See also http://www.w3.org/TR/html-bidi/#vertical-scrollbar-body.

I think Simon's right in comment 3. This is a serious issue for all RTL web content which makes use of textarea. Requesting the blocking flag for the next release.

There is another problem: the resizing cursor doesn't change from SE to SW for RTL, even though the resizer icon does.

Checked in with added comment: http://hg.mozilla.org/mozilla-central/rev/b2726997982c

Verified. However, this doesn't solve two other issues in comment 2 (the resizer overlaying the text, and the directionality of the resizer operations. I'll file new bugs for those issues. Also, it's trivial to create a reftest for this bug. Simon, could you please do that? Thanks!

(In reply to comment #8) > However, this doesn't solve two other issues in comment 2 (the resizer > overlaying the text, and the directionality of the resizer operations. Filed those issues as bug 558201 and bug 558203.

(In reply to comment #8) > However, this doesn't solve two other issues in comment 2 (the resizer > overlaying the text, and the directionality of the resizer operations. s/operations/cursor/ !

(In reply to comment #8) > Also, it's trivial to create a reftest for this bug. Simon, could you please > do that? Thanks! The only reftest I can think of is a non-identity test for empty rtl and ltr text-areas with "overflow: scroll". Did you have something else in mind?

(It will also have to be with "-moz-resize: none" to ensure that it fails without this fix)

Yeah, what I had in mind was: != rtl-textarea.html ltr-textarea.html != textarea-in-rtl-doc.html textarea-in-ltr-doc.html != rtl-textarea.html nonresizable-textarea.html And maybe: != ltr-textarea.html nonresizable-textarea.html if there isn't already such a reftest.

The textarea-rtl != textarea-no-resize test failed on Linux (http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271061495.1271062664.2951.gz), which is the same thing that Ehsan already mentioned in bug 558201 comment 2. I don't see that on my Linux box, so I marked it random: http://hg.mozilla.org/mozilla-central/rev/201589e94d3b

(In reply to comment #15) > The textarea-rtl != textarea-no-resize test failed on Linux > (http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271061495.1271062664.2951.gz), > which is the same thing that Ehsan already mentioned in bug 558201 comment 2. I > don't see that on my Linux box, so I marked it random: > http://hg.mozilla.org/mozilla-central/rev/201589e94d3b Thanks, I commented on that bug about this.

It's also failing on Vista... bug 562963. I think the problem is just that the textarea is too small for the minimum length for a scrollbar, so we just drop the vertical scrollbar because there's not room for it. I think we should just make the textareas bigger. (Also, I noticed there's no resizer at all on textarea-rtl.html . Is there a bug on that?)

Er, sorry, it's a different test failing on Vista, so ignore my previous comment. And the problem I'm seeing is the one Ehsan mentioned in bug 558201 comment 2 (although I'm not sure it has its own bug).

(In reply to comment #18) > Er, sorry, it's a different test failing on Vista, so ignore my previous > comment. And the problem I'm seeing is the one Ehsan mentioned in bug 558201 > comment 2 (although I'm not sure it has its own bug). Apparently I had forgot to file a bug on that, thanks for mentioning this. I've now filed bug 563085.

(Tested in Firefox 4.0b7 locale=zh-tw on Windows) Going back to the original example in the URL field, I found it very hard to resize the <textarea> because the resizer is too close to the edge of my monitor and there's no enough space for the cursor to stretch out. Consider the following example (ltr <textarea> aligned on the right side), data:text/html;charset=utf8,<p style="text-align: right;"><textarea cols=20 rows=2>Test!</textarea></p> I am wondering whether the position of the resizer should depend on the value of 'text-align' instead of 'direction', which affects the default behavior of 'text-align' of course. The current behavior that the position of the scroll bar depends on 'direction' makes sense so if the scroll bar and the resizer have to be bound together no matter what than I guess the current behavior is optimal.

Actually, I start to wonder whether the position of the scroll bar should depend on 'direction' or 'text-align'.

(In reply to comment #21) > Actually, I start to wonder whether the position of the scroll bar should > depend on 'direction' or 'text-align'. It should not have any connection to alignment, only to direction. Direction says which side is the start and which side is the end. Scrollbars belong on the end. Alignment normally belongs on the start. If someone changes the alignment, it should not have any effect on scrollbar position.