Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090209 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090209020514 Going to preferences and opening the main panel the URL for the home page is right aligned. This is different from the location bar. As Ehsan has written in a private message, URLs are left-to-right inherently, so for the location bar we keep LTR. Given that fact we should also have the same alignment for the homepage textbox. Probably this happens on all platforms.

Same applies to the Library where all the URLs are right aligned. Is it expected there or shall I file a separate bug on that?

Please note that we have done workarounds in the past using the intl.css file, which might be different between RTL locales. We wish to get rid of this file and have every issue solved in the theme itself, but some of the issues have workarounds there. Here is the Hebrew version of the file, replace 'he' with 'ar' or 'fa' for other locales. http://mxr.mozilla.org/l10n/source/he/toolkit/chrome/global/intl.css And here what *should* fix this issue, but it is possible the dialog source have been changes since this directive placed there. /* set LTR for url and file paths and align them to the right - Bug 289934 */ #link-url-text, #source, #path, #url, #feedurl, #downloadFolder, #urltext, #statusbar-display { direction: ltr !important; text-align: right !important; }

(In reply to comment #1) > Same applies to the Library where all the URLs are right aligned. Is it > expected there or shall I file a separate bug on that? Please see bug 427026. If you see more of this problem in the Library window than that bug fixes, please file them as a separate bug. Also, as a general note, it would be good if you can test RTL problems on trunk as well as 1.9.1, since I have landed a number of RTL fixes on trunk which are waiting approval for 1.9.1. (In reply to comment #2) > Please note that we have done workarounds in the past using the intl.css file, > which might be different between RTL locales. We wish to get rid of this file > and have every issue solved in the theme itself, but some of the issues have > workarounds there. Actually the correct fix would be to add the uri-element class on the XUL element. I'll post a patch shortly.

Does this affect the nested autocomplete popup?

(In reply to comment #5) > Does this affect the nested autocomplete popup? The autocomplete popup is also displayed LTR, with icons on the left side, which is what we want here. BTW, this is not specific to the 3.1 branch, and it affects trunk as well.

Comment on attachment 361631 [details] [diff] [review] Patch (v1) > BTW, this is not specific to the 3.1 branch, and it affects trunk as well. The fact that it's not specific to trunk and affects the branch seems more important. :)

(In reply to comment #7) > The fact that it's not specific to trunk and affects the branch seems more > important. :) As long as we know it affects both versions, I'm fine either way. :-)

(In reply to comment #3) > Please see bug 427026. If you see more of this problem in the Library window > than that bug fixes, please file them as a separate bug. Also, as a general Ok, has to be filed as a new bug. Will do so in a minute. > note, it would be good if you can test RTL problems on trunk as well as 1.9.1, > since I have landed a number of RTL fixes on trunk which are waiting approval > for 1.9.1. I know and I already did that. The major problem is, that most of the locales on trunk don't even work. So I can only use your extension to check the stuff on trunk.

(In reply to comment #9) > I know and I already did that. The major problem is, that most of the locales > on trunk don't even work. So I can only use your extension to check the stuff > on trunk. I recently made sure that fa is updated for trunk as well, so you can use fa nightlies. I usually monitor the fa dashboard, but any time that you notice that the fa build on trunk is out of date, let me know and I'll fix it in time for the next nightly. :-)

Comment on attachment 361631 [details] [diff] [review] Patch (v1) This is a very low risk patch which fixes a direction problem for RTL locales on all platforms. Requesting approval to land it on 1.9.1.

Ehsan, I wonder why this is already displayed ltr for Shiretoko or even Minefield builds earlier than 090214. The language pack I use is from 090211.

(In reply to comment #13) > Ehsan, I wonder why this is already displayed ltr for Shiretoko or even > Minefield builds earlier than 090214. The language pack I use is from 090211. It should be because of this rule in fa's intl.css: #browserHomePage, #userAgent, #ToolbarEval > #TextboxEval { direction: ltr !important; } <http://hg.mozilla.org/l10n-central/fa/file/0192648c79c9/toolkit/chrome/global/intl.css#l59> In fact, most of the "direction: ltr !important;" rules there should probably be fixed in the code itself (and not remain as intl.css hacks). It would be great if you have time to go through them and file bugs, and I'll provide the patches. :-) To do that, you need to search for each ID in the CSS in MXR, and find out which portion of the UI that ID is referring to, and file the appropriate bug.

Comment on attachment 361631 [details] [diff] [review] Patch (v1) a191=beltzner

(In reply to comment #14) > be fixed in the code itself (and not remain as intl.css hacks). It would be > great if you have time to go through them and file bugs, and I'll provide the > patches. :-) To do that, you need to search for each ID in the CSS in MXR, > and find out which portion of the UI that ID is referring to, and file the > appropriate bug. Sorry, but I don't have time for that. I can help in identifying UI problems but that's all for now.

(In reply to comment #17) > Sorry, but I don't have time for that. I can help in identifying UI problems > but that's all for now. No worries, and thanks a lot for all your help so far! :-)

Verified on trunk and 1.9.1 branch with builds on OS X and Windows: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fa; rv:1.9.2a1pre) Gecko/20090221 Minefield/3.2a1pre ID:20090221020633 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fa; rv:1.9.1b3pre) Gecko/20090221 Shiretoko/3.1b3pre ID:20090221020541