In an RTL textarea where a line wraps to the next line (e.g. the upper textarea in https://bugzilla.mozilla.org/attachment.cgi?id=128682), the caret is stuck when you try to use left-arrow to move beyond the wrapping point (i.e. from the first line to the second one). The same happens when you try to use right-arrow to go back from the second line to the first one. This regressed due to the patch for bug 305083, and is now both on the trunk and on the 1.8 branch. Needless to say, this is very major, and must be fixed for beta 2.
Created attachment 195610 [details] [diff] [review] patch Only "unflip" the hint when we know the inner call might want to flip it itself. I actually explained why this is necessary back in bug 207186 comment #28 (describing this regression if it's not done), but then forgot about it when reviewing the patch for bug 305083.
Comment on attachment 195610 [details] [diff] [review] patch I'll take your word for it, I can't really do any serious reviewing. It would of course be more easy to understand if every mAmount could accept the original unmodified mPreferLeft and change it according to whatever logic it employs, but the whole thing can't be made simple and understandable anyway, so let it be as the patch suggests. Sorry for not having caught this either.
Comment on attachment 195610 [details] [diff] [review] patch rubber-stamp. This code has to be rewritten on trunk.
Checking in nsTextFrame.cpp; /cvsroot/mozilla/layout/generic/nsTextFrame.cpp,v <-- nsTextFrame.cpp new revision: 1.525; previous revision: 1.524 done
1.8 Branch: Checking in nsTextFrame.cpp; /cvsroot/mozilla/layout/generic/nsTextFrame.cpp,v <-- nsTextFrame.cpp new revision: 1.513.4.5; previous revision: 1.513.4.4 done
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).