In any RTL textarea (such as the top textarea in the provided testcase URL), start typing. A horizontal scrollbar will appear, and the scroll thumb will shrink as you type. Interestingly, deleting characters has the same effect. Seen this in a 2005-08-13 nightly. This WFM in Camino 0.8.4.

Regression window is between 2005-06-27-08 and 2005-06-28-08. Checkins: http://tinyurl.com/9cmdq

I'd guess bug 274036 from that regression window. Targeting for 1.0 for now.

I'd like to emphasize that this is not a cosmetic issue: the logical width of the textarea really grows with each keypress, meaning, among other things, that text typed into the textbox never wraps. This makes RTL textboxes pretty much unusable. I'm not sure what Camino's priorities and policies are, but I would have considered this a blocker for any public release.

The 0.9 milestone target is essentially meaningless now because there will be no 0.9 release, so this bug targeted to be fixed for the next release :-) (Bugs still on the 0.9 list are either longstanding unresolved issues from when 0.9 was to be a release or new dataloss or serious perf issues that need to be tackled asap.) Currently in Camino, blockers are not managed separately (i.e., with flags) from the list based on target milestone.

(In reply to comment #3) > I'd like to emphasize that this is not a cosmetic issue: the logical width of > the textarea really grows with each keypress, meaning, among other things, that > text typed into the textbox never wraps. This makes RTL textboxes pretty much > unusable. Is this really Camino-only?

(In reply to comment #5) > Is this really Camino-only? Yes. (At least it's not affecting Firefox. I haven't checked SeaMonkey).

This appears to be triggered by the following (Camino-specific) lines in forms.css: textarea > .anonymous-div { padding: 0px 0px 0px 2px; } Adding this padding to the general (non-Camino-specific) block generates the same problem in Firefox. Notice that these lines were added as part of the check-in for bug 298111, which happened on 2005-06-24 -- but the regression appeared only three days later. All of this means that there might be an underlying non-Camino bug here.

I opened bug 306349 for the underlying core bug.

Uri, do you think there is anything we can do on the Camino end (aside from backing out the changes to make the textareas look like Mac OS X ones) to fix this, or is this completely dependent on the Core bug being fixed? (I actually want to increase the padding on the top and the right yet--bug 298111 comment 9 item 2--but presumably any l/r padding causes the problem....)

How about using margins instead of padding? A quick test (on Firefox) indicates that the visual effect is similar, without triggering the RTL bug. There might, however, be some delicate issues which I missed.

I had the same thought shortly after making that comment. The delicate issue I've come across so far is scrollbars. You can't use top, bottom, or right margins or the scrollbars have white space between them and the edge of the textbox. You can't have left or right padding because of bug 306349. With a combination of the margins and padding (top and bottom padding, left margin), you can reproduce the current Camino appearance and improve the top/bottom tightness of text (text is still too tight on the right, but it is currently). However, trying to do a left margin messes things up in RTL textareas, because the scrollbar is on the left and now has whitespace between it and the edge of the textarea. Is there a selector we can use to special-case the RTL textareas and give them an inverted set of rules? There might still be more delicate issues out there. In addition to the testcase in the URL field, I've been using https://bugzilla.mozilla.org/attachment.cgi?id=186717 and https://bugzilla.mozilla.org/attachment.cgi?id=187626 to help watch things. We really need bug 306349 fixed, but if we can special-case RTL textareas, we might be able to work around the bug and still improve the appearance (except the tightness of the text to the opposite-from-scrollbar edge) for Camino 1.0.

(In reply to comment #11) > However, trying to do a left margin messes things up in RTL textareas, because > the scrollbar is on the left and now has whitespace between it and the edge of > the textarea. Is there a selector we can use to special-case the RTL textareas > and give them an inverted set of rules? I don't think you can do that, but what you can do (and might work) is to use -moz-margin-start instead of margin-right. -moz-margin-start (and -moz-margin-end) were introduced in bug 74880 (after a discussion of the possibility of using direction-related CSS selectors). You might find more useful stuff in the discussion there.

One can't have *any* sort of left or right margin (or a -moz-margin-start; cool tip!) because that then causes gaps between the horizontal scrollbar and the l/r/start edge of the textarea. I don't know how I missed that earlier :-( So I think we're back to bug 306349 gets fixed, or we back out the textarea changes and fix this bug, or we leave the textarea changes and keep this bug.

(In reply to comment #13) > So I think we're back to bug 306349 gets fixed, or we back out the textarea > changes and fix this bug, or we leave the textarea changes and keep this bug. If it's not too late, you might want to consider taking the patch on bug 312550 on the Camino 1.0 branch (assuming such a branch exists). That patch fixes bug 306349, among other things. Although that patch is yet to be landed on the trunk, I think taking it for Camino is not a big risk, as it can only affect RTL, which is pretty broken in Camino without the patch.

Per Uri's last comment, nominating for 1.0 so we can discuss taking the fix for bug 312550 to fix this on the release mini-branch (which I assume we're going to have to get the Camino fixes in the latest JEP at least...).

Uri just landed bug 312550 on the branches, so this should be fixed for Camino 1.0 and 1.x (I'll check tomorrow's build and resolve fixed unless someone else does first).

Not that I doubted Uri, of course--only the mozilla build machinery :-)

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).