295686 - intl.css (chrome://global/locale/intl.css) is ignored in SeaMonkey

Status: RESOLVED INCOMPLETE

(SeaMonkey :: UI Design, defect)

Description

[Tsahi Asher]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; he-IL; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; he-IL; rv:1.7.5) Gecko/20041217

mozilla suite ignores the css rules set in chrome://global/locale/intl.css when
a language pack is used. this is critical for RTL locales (hebrew, arabic etc.)
since we use this file to set "direction: rtl" on the chrome, to align the UI to
the right.



Reproducible: Always

Steps to Reproduce:
1. install the hebrew language pack from
http://prdownloads.sourceforge.net/hebmoz/langheil1.7v1.3.xpi?download (this
pack is intended for mozilla 1.7.5, but i believe it will work on other 1.7.x
versions too)
2. switch to hebrew language pack
3. see LTR UI

you can also use DOM inspector to see that mozilla doesn't know about the rules
set in intl.css of the hebrew language pack when it is active.
Actual Results:  
UI is aligned left, with text flow from left to right

Expected Results:  
UI should be right aligned, with text flow from right to left.

in the past, this happened sometimes, and if it did, usually a switch back to
en-US and then again to the language pack fixed this. but now this doesn't help
anymore.

the workaround i found is as follows:
1. switch to hebrew language pack
2. close mozilla,
3. rename chrome/en-US.jar to something else
4. open mozilla
5. rename en-US.jar back to it's original name.

i know the build i'm using is a bit old. i hope to try it on newer builds soon,
once i create a language pack for them. again, you can try the linked language
pack on newer builds.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Simon Montagu :smontagu]

Confirming bug, but if I specify the profile from the command line rather than
using the profile manager it works.

Comment 3

[Wayne Mery (:wsmwk)]

related Bug 299505

Comment 4

[Wayne Mery (:wsmwk)]

smontagu, et al, should this be duped to bug 299505? Or is it better to mark depends on bug 299505?

Comment 5

[Tsahi Asher]

i think it should depend, if any.

Comment 6

[Simon Montagu :smontagu]

This is a separate issue from bug 299505.

Comment 7

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 8

[Tsahi Asher]

in the latest seamonkey this sometimes happens. closing the app and opening again (even with turbo launch on) usually corrects the problem. on the other hand, i didn't update the language pack for some time now, since 1.1.2.

Comment 9

[Robert Kaiser]

Incomplete. There's not enough info here to tell if this is a consistent problem with any SeaMonkey version at all, and surely not if this is still any kind of issue in trunk.