477696 - [RTL] Homepage URL in preferences is right aligned instead of left aligned

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 2

[Tomer Cohen :tomer]

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;
 }

Comment 3

[(no longer active)]

(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.

Comment 4

[(no longer active)]

Attachment: Patch (v1)

Comment 5

[Dão Gottwald [:dao]]

Does this affect the nested autocomplete popup?

Comment 6

[(no longer active)]

(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 7

[Dão Gottwald [:dao]]

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. :)

Comment 8

[(no longer active)]

(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.  :-)

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.

Comment 10

[(no longer active)]

(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 11

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/560022052864

Comment 12

[(no longer active)]

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.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 14

[(no longer active)]

(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 15

[Mike Beltzner [:beltzner, not reading bugmail]]

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

a191=beltzner

Comment 16

[(no longer active)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0b9990b4d8a7

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.

Comment 18

[(no longer active)]

(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!  :-)

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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