183211 - font-size: 0.8em; becomes invisible

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Jens Jäger]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021202
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021202

Mozilla 1.2.1 is correct. If the font-size in the CSS is smaller than 1.0em the
latest trunk does not render this text.

Reproducible: Always

Steps to Reproduce:
1. go to http://www.mozillazine.org/
2. try to read text with class="stryTxt"
3.

Actual Results:  
text with class="stryTxt" is invisible

Expected Results:  
text should render correctly (like mozilla 1.2.1)

if I alter the font-size in http://www.mozillazine.org/frontpage.css to
"font-size: 1.0em;" then the text is visible

Comment 1

[Jens Jäger]

Attachment: my testcase

simple testcase to show the error

Comment 2

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

Are you using Xft or non-Xft?  I don't see the problem on my Xft Linux build
from yesterday.  (Are you using the morning build or the evening build?)

Comment 3

[Jens Jäger]

I use Mozilla 2002120221 without XFT (normal Mozilla Trunk) under Redhat 8.0.
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-sea.tar.gz

Comment 4

[Jens Jäger]

I reproduced the bug with a new profile in Mozilla 2002120304 and without any
plugins.

Comment 5

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

Worksforme in a fresh profile in 2002120304 (tarball) on RH8.

Comment 6

[Boris Zbarsky [:bzbarsky]]

worksforme, linux trunk build 2002-12-01-21 (non-xft)....  Has this regressed
since then?

Comment 7

[Jens Jäger]

I tried some trunks and here are the results:
Build 2002112905 works
Build 2002120121 works
Build 2002120221 is faulty
Build 2002120304 is faulty

Comment 8

[Madhur Bhatia]

works for me on redhat linux 8.0 (non-xft) on 2002-12-03-04trunk build

marking it WFM for now 

Comment 9

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

WORKSFORME is described as "All attempts at reproducing this bug were futile",
and I don't think that's appropriate for this bug.  Reopening, at least until we
have a better understanding of the problem.

Comment 10

[R.K.Aa.]

Confirming bug. Page is mostly white - little or no text, when testing with a
trunk CVS build, Linux - around 8 hours old. I also notice that line-height is
completely trashed from 1.4 to 1em in a little "FAQ" i have about mozilla;
http://home.online.no/~rut-aane/My_Mozilla_FAQ.html
But there the text is rendered.

Comment 11

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

Could you try build 2002-12-02-04-trunk ?  (Since I don't see the bug I'm going
to need help from people who do in order to figure out a potential cause.)

Comment 12

[R.K.Aa.]

Attachment: screenshot, linux, 2002120309

It's a bug in the very latest nightly - just downloaded official.
Pulling CVS now.

Comment 13

[R.K.Aa.]

identical result with 2002120205, sea.tar.gz Linux. (is faulty)

Comment 14

[R.K.Aa.]

2002-12-02-04-trunk = 2002120205 Linux
Btw, meyerweb.com looks rather.. compact with this bug as well.

Comment 15

[R.K.Aa.]

followed bz's suggestion and backed out checkins for bug 165877, and the bug is
gone again:

cvs update -j1.152 -j1.151 mozilla/string/obsolete/nsString2.cpp
cvs update -j3.175 -j3.174 mozilla/string/obsolete/nsString.cpp

Comment 16

[Boris Zbarsky [:bzbarsky]]

ccing some culprits.  I bet that ToFloat() fails somewhere now, the caller does
not notice, and we end up with a "0" for the font-size or something....

Comment 17

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

What does "setenv | grep LC_ALL" tell you?

Comment 18

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

If I do "setenv LC_ALL fr_FR" I see the bug.  strtod is presumably
locale-sensitive, and we don't want ToFloat to be locale sensitive or it will do
different things in locales that use ',' where Americans use '.'.

Comment 19

[R.K.Aa.]

[dark@localhost src]$ locale
LANG=no_NO
LC_CTYPE="no_NO"
LC_NUMERIC="no_NO"
LC_TIME=no_NO
LC_COLLATE="no_NO"
LC_MONETARY="no_NO"
LC_MESSAGES="no_NO"
LC_PAPER="no_NO"
LC_NAME="no_NO"
LC_ADDRESS="no_NO"
LC_TELEPHONE="no_NO"
LC_MEASUREMENT="no_NO"
LC_IDENTIFICATION="no_NO"
LC_ALL=

Comment 20

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

Attachment: patch

This fixes it for me (testing with fr_FR).

Comment 21

[Boris Zbarsky [:bzbarsky]]

OK.  At about the same time as dbaron posted that comment rkaa and I finished up
our little printf-session and indeed the parse stops at '.' in that locale, thus
ToFloat drops everything after the '.' _and_ returns failure (it would be nice
if the CSS scanner checked for that or something).

Oh, and switching back to PR_strtod in ToFloat fixes the bug of course.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 108135 [details] [diff] [review]
patch

I seem to be one step behind dbaron.  ;)

Comment 23

[Marek Stępień [:marcoos, inactive]]

If I set

export LC_ALL="en_US"

and run Mozilla, there is no problem.

But, if I use my native language locale setting:

export LC_ALL="pl_PL"

it looks the same as on the screenshot from comment #13.
The same problem appears if I set LC_ALL to "de_DE" (German) or "it_IT" (Italian).

Polish locale use a comma (",") as the separator, while American English uses a
dot (e.g. ten and a half is 10,5 in Polish and 10.5 in American English).

This is Gecko/20021203, non-xft, from sea.tar.gz, on Slackware Linux 8.1.01. (I
downloaded it on Tuesday evening CET)

Comment 24

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

Fix checked in, 2002-12-03 20:43 PDT.

Comment 25

[Daniel Bratell]

Ah, so that was the reason for PR_strtod. Good you added the comment.

Comment 26

[Madhur Bhatia]

verified