146673 - LC_ALL causes Slashdot display incorrectly in Mozilla 1.0

Status: RESOLVED DUPLICATE of bug 159328

(Core :: XPCOM, defect)

Description

[cartman]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523
BuildID:    20002052309

slashdot.org news pictures are aligned left but they have to be aligned on the
right.

Reproducible: Always
Steps to Reproduce:
1.Open www.slashdot.org



Actual Results:  News pictures are aligned left

Expected Results:  They have to be aligned right

Comment 1

[cartman]

Attachment: Snaphot of slashdot

Comment 2

[Jo Hermans]

WFM on Windows NT on build 2002052306 (1.0 RC3)

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc3) Gecko/20020523

Comment 3

[Gilles Durys]

wfm with rc3 and 2002052322 trunk on linux

Comment 4

[Liam Howlett]

Adding the allign="left" to the inner table or td seems to `fix` this.

Comment 5

[cartman]

I can confirm that "Adding the allign="left" to the inner table or td  fix the
issue."

Comment 6

[Chris Waterson]

Confirming.

Comment 7

[cartman]

Attachment: Tar package of the site

Comment 8

[Chris Waterson]

Hmm, I unpacked attachment 84912 [details] in a local directory, and things still look
okay for me (I'm using a trunk build). Have you done any tinkering with your
profile settings? (I'm not sure what would cause floats to lay out this way, but...)

Comment 9

[cartman]

i rm  -rf ed ~/.mozilla and started with a  vanilla profile still same

Comment 10

[Chris Petersen]

Checked the slashdot site and layout of page looks correct. WFM using the Linux
branch (2002-05-24-09 1.0.0) and OS X branch (2002-05-23-05 1.0.0). 

Comment 11

[cartman]

I checkout from trunk and compiled build 2002052419 still the same can be based
on any *external* libs?

Comment 12

[cartman]

This bug doesnt show up in Mozilla 1.0 rc2 so i did ldd mozilla-bin for both Rc
2 and Rc 3 and comprated them and saw that rc2 has two more libs than rc3 that are

libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x1591d000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x15b73000)

Maybe this helps some...

Comment 13

[joakim_46]

WFM with build 2002052306 under Windows ME.

Comment 14

[Greg Holloway]

WFM (RC3 on Linux).

Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0rc3) Gecko/20020523

Comment 15

[R.K.Aa.]

WFM, linux trunk official build as well as home-brew CVS with gcc-2.96-98 and
optimize=O2.

Sounds like a local configuration error -> invalid.

Comment 16

[cartman]

Tried with already compiled binaries , and ones compiled with -02,-03 and no
optimizations still same.

Comment 17

[R.K.Aa.]

Weird. Did you delete cache before loading the site with the official builds?

Comment 18

[cartman]

Yes really weird I deleted cache & deleted profiles still no luck. I am starting
to think that some external library may affect this behaviour but cant figure
out what.

Comment 19

[cartman]

As far as this bug only seen on my machine and i got 1-2 segfaults on other
program i resolve this to INVALID. Thnaks for the help though.

Comment 20

[Laura Krietemeyer]

Changing QA Contact

Comment 21

[Moied]

verified

Comment 22

[cartman]

I am re-opening bug because I found the reason why I see it how fix it and
reproduce it. Thing is the LC_ALL variable in /etc/profile if you open
/etc/profile and set the LC_ALL variable to something other than POSIX like set
it to tr_TR . Logout login then go to slashdot site is dispplayed wrong and some
submit buttons are unclickable if you set back the LC_ALL vraible to POSIX its
all ok.

This only applies to Rc3+ , Rc2 and older builds dont see this weird behaviour.
And a fast workaorund is adding export LC_ALL=POSIX to mozilla start-up script.

I think this is related to the patch that is about using local unix charset
defined in system thats why rc2 is immune but rc3+ doesnt. 

P.S : It would be good to add this to release notes.

Comment 23

[Mathieu Pillard [:mat]]

setting my LC_ALL to fr_FR, no problems at all.
setting my LC_ALL to tr_TR, I can see the bug...

thereforce I suspect this have to do with *some* locales, but not all :)

Comment 24

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

mmm.  So it sounds like we could be using C library functions that are
locale-dependent.

Comment 25

[cartman]

This  still exists in Mozilla 2002081611 on Linux. Is there is a progress on
this bug ?

Comment 26

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Giving to alecf since I suspect the tolower/toupper removal he was going to do
for another bug will probably fix this as well.

Comment 27

[Alec Flett]

*** This bug has been marked as a duplicate of 159328 ***