436190 - Find Updates button is cut in addons manager for RTL locales

Status: RESOLVED WORKSFORME

(Mozilla Localizations :: he / Hebrew, defect)

Description

[Tsahi Asher]

Mozilla/5.0 (Windows; U; Windows NT 5.1; he; rv:1.9) Gecko/2008051206 Firefox/3.0

when the UI is reversed to RTL (e.g. in Hebrew locale, but most likely Arabic and Persian too), the "Find Updates" (or is it Get Updates? i have the Hebrew version) button at the bottom of the addons manager is cut, so that it's lower third is outside the window and not visible.

the button is visible in the Extensions and Themes tabs.

Comment 1

[Kai Liu]

Attachment: screenshot

Looks like a general RTL problem (not specific to any language)

Comment 2

[Kai Liu]

Here's the problem:

he: <http://bonsai-l10n.mozilla.org/cvsblame.cgi?file=/l10n/he/toolkit/chrome/global/intl.css&rev=1.7&mark=21-25#21>

ar: <http://bonsai-l10n.mozilla.org/cvsblame.cgi?file=/l10n/ar/toolkit/chrome/global/intl.css&rev=1.3&mark=25-29#25>

fa: <http://bonsai-l10n.mozilla.org/cvsblame.cgi?file=/l10n/fa/toolkit/chrome/global/intl.css&rev=1.3&mark=21-25#21>

Comment 3

[Kai Liu]

I wonder if using visibility: hidden would be better, as that would leave the space around.

Comment 4

[Tsahi Asher]

or maybe it's time we fix the resizer bug - bug 240536.

Comment 5

[Kai Liu]

Yea, that sounds like the right thing to do.  I was taking a look at that earlier today.  It's very easy to fix on Windows (just requires something similar to what we are doing for RTL menu popup arrows), but I dunno about Linux/Mac.

Comment 6

[Yehuda]

Attachment: Add-on window on Mac OSX

Screen shot for Mac OS X shows that the button is visible, but still too close to the bottom of window to feel "comfortable".

Comment 7

[(no longer active)]

(In reply to comment #5)
> Yea, that sounds like the right thing to do.  I was taking a look at that
> earlier today.  It's very easy to fix on Windows (just requires something
> similar to what we are doing for RTL menu popup arrows), but I dunno about
> Linux/Mac.

I gave it a shot, but couldn't get it to work correctly.  Have you tried it in terms of a patch?

Comment 8

[Kai Liu]

(In reply to comment #7)
> I gave it a shot, but couldn't get it to work correctly.  Have you tried it in
> terms of a patch?
> 

I have a WIP patch, but I haven't gotten around to testing it (compiling takes so long, and I'm a little busy)... here's my general approach:

1) Update the appearance of -moz-appearance: resizer (it seems to be used only for Windows and Linux, and it looks like the Linux one is already RTL-friendly, so only the Windows one needs updating; I have no idea where the Mac theme is getting its resizer graphic--could it be built into the window somehow?)

2) Update xul:resizer.  The best way to do this, IMHO, is to add a new "bottomcorner" direction to resizer and have that map to either "bottomright" or "bottomleft" in nsResizerFrame::EvalDirection depending on the frame direction.

3) Update the consumers of xul:resizer.  Change all uses of bottomright to bottomcorner (if that's the approach taken in step 2) and also add a chromedir to it (so that the CSS can determine whether to assign it a se cursor or a sw cursor).

Comment 9

[(no longer active)]

(In reply to comment #8)
> I have a WIP patch, but I haven't gotten around to testing it (compiling takes
> so long, and I'm a little busy)... here's my general approach:

This might help with the compilation times problems: :-)
<http://ehsanakhgari.org/blog/2008-05-29/how-test-your-mozilla-patch-faster>

> 1) Update the appearance of -moz-appearance: resizer (it seems to be used only
> for Windows and Linux, and it looks like the Linux one is already RTL-friendly,
> so only the Windows one needs updating; I have no idea where the Mac theme is
> getting its resizer graphic--could it be built into the window somehow?)

No idea, I don't even have a Mac!

> 2) Update xul:resizer.  The best way to do this, IMHO, is to add a new
> "bottomcorner" direction to resizer and have that map to either "bottomright"
> or "bottomleft" in nsResizerFrame::EvalDirection depending on the frame
> direction.

Hmm, there's no such thing as a XUL resizer per se.  This is all there is to it: <http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/themes/winstripe/global/global.css&rev=1.13&mark=163-166#163>  I agree that bottomcorner is much better than bottomright, though.

> 3) Update the consumers of xul:resizer.  Change all uses of bottomright to
> bottomcorner (if that's the approach taken in step 2) and also add a chromedir
> to it (so that the CSS can determine whether to assign it a se cursor or a sw
> cursor).

Agreed.

Comment 10

[Kai Liu]

I finally got around to compiling and testing my patch to cover 1&2 from comment 8, and I've posted it to bug 240536 comment 7.  Let's continue the discussion there.  :)  Anyway, off to grab dinner...

Comment 11

[(no longer active)]

(In reply to comment #3)
> I wonder if using visibility: hidden would be better, as that would leave the
> space around.

FWIW, we implemented this solution for fa:

<http://bonsai-l10n.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=intl.css&branch=&root=/l10n&subdir=l10n/fa/toolkit/chrome/global&command=DIFF_FRAMESET&rev1=1.4&rev2=1.5>

Comment 12

[Tomer Cohen :tomer]

Attachment: Add-ons window on Linux/GTK screenshot

Comment 13

[(no longer active)]

Tomer: the patch should be pretty simple, based on <http://bonsai-l10n.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=intl.css&branch=&root=/l10n&subdir=l10n/fa/toolkit/chrome/global&command=DIFF_FRAMESET&rev1=1.4&rev2=1.5>.  Let me know if you have any problems in the process.

Comment 15

[Samuel Sidler (old account; do not CC)]

If this bug affects all rtl locales and the fix won't be specific to them, should this be moved to the Firefox product?

Comment 16

[Kai Liu]

(In reply to comment #15)
> If this bug affects all rtl locales and the fix won't be specific to them,
> should this be moved to the Firefox product?
> 

The permanent solution (make the gripper work) will take place entirely in another bug and will require no action of any sort from l10n.  The workaround solution for 3.0.x is what this bug is mostly about, and this workaround (which does not affect the permanent solution) involves modifying a CSS file in l10n/, so it's not appropriate to move this to Firefox, though it would be appropriate to clone this bug for ar...

Comment 17

[Samuel Sidler (old account; do not CC)]

Ah, alright. I'm taking this off the wanted list then. If a workaround patch is made for l10n, it just needs to get approval before landing but doesn't need to be part of any wanted or blocking lists.

Comment 18

[(no longer active)]

Cloned for ar (bug 451052).  It's already fixed in fa.

Comment 19

[Someone]

Cant the fix from the Arabic version be ported to the Hebrew version?

Comment 20

[(no longer active)]

(In reply to comment #19)
> Cant the fix from the Arabic version be ported to the Hebrew version?

Now that bug 240536 is fixed, this workaround is actually not needed at all, as the resizer widget now supports RTL mode properly.  I guess this is WORKSFORME now.