User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2 The attachment (which I'll upload in a moment) should say it all, if it screws up for other people too. I tried some simple-minded variations, e.g., changing text-decoration and font-weight to other values, but any variation seemingly makes the bug disappear, as you should be able to see. Sorry for not putting a little more effort into filing this, like testing on a nightly, but I hope this is helpful anyway. I'd be gratified if I see someone else say they get the same thing, to prove I'm not hallucinating. :) Reproducible: Always Steps to Reproduce: Visit attachment. Actual Results: The first "Foo" is displayed struck through, possibly in a lighter-than-usual font. Expected Results: A black box is displayed in place of the first "Foo". All others display normally.

Confirmed that the issue is still present in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008020404 Minefield/3.0b3pre. Not present in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11.

Not present in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

Not seeing this in Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b4pre) Gecko/2008020504 Minefield/3.0b4pre Could you attach a screenshot and tell more about your distribution or if you have a special configuration?

This is how the previous attachment displays for me in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2. My setup is Ubuntu 7.10, using GNOME with the proprietary NVIDIA driver 100.14.23 for Linux-x86. Visual Effects are set to None in System -> Preferences -> Appearance, which I guess means Compiz is disabled. I'm using linux-image-2.6.24-4-generic from the Hardy repository, IIRC, and the corresponding NVIDIA driver, because 2.6.22 didn't boot on my current motherboard unless I disabled ACPI. I can't think of anything else that would be relevant.

Confirmed that this does *not* occur for me either, in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020504 Minefield/3.0b4pre. Maybe this is a regression that's since been fixed. What's the difference between 3.0b3pre and 3.0b4pre?

So you say it fails with 2008020404 and works in 2008020504. That's strange because I don't see something font related in that range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-04+04%3A00&maxdate=2008-02-05+04%3A00&cvsroot=%2Fcvsroot 3.0b3pre or 3.0b4pre are version identifiers used between official releases, the interesting part is the build date (2008020404) if you want to compare things.

Okay, I've got it. It's the profile, not the version. With my default profile, it fails in all the ff3.0b I've mentioned (although not ff2, which the profile was imported from). With a freshly-created profile that I made to avoid weird stuff happening with opening my normal profile in a succession of different versions, the issue does not occur. Using safe mode appears to make no difference (but I didn't test that extensively). What further diagnostics should I perform?

> Using safe mode appears to make no difference (but I didn't test that extensively). Do you mean that you still see the issue in safe mode? > What further diagnostics should I perform? First backup your profile with which you see the issue. Then try to find if it is related to add-ons (you can disable them with the safe-mode window), or some preference you have set (can also be reset with safe-mode). You can then narrow it to the add-on or preference that makes this behavior happen (editing prefs.js in your profile while Firefox is not running can be a fast way to reset lots of preferences).

Okay, I bisected prefs.js and found the culprit: user_pref("font.default.x-western", "sans-serif"); The attached HTML file reliably reproduces the issue for me on a (practically) fresh profile in 3.0b2, with no extensions enabled, etc. (The only difference is style="font-family: sans".) Can other Linux users see the problem now? I think the issue is related to the exact font "Sans". I haven't retested on a nightly or made a totally fresh profile because there was no difference before, but I can if there are still issues reproducing it.

Thanks for the investigations, I can now reproduce this. regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-10-05++04%3A00%3A00&maxdate=2007-10-06++04%3A00%3A00&cvsroot=%2Fcvsroot -> regression from bug 362682 The striking metrics returned by Pango are somewhat totally wrong with sans + font-weight: lighter: data:text/html,<span style="font-family: sans; font-weight: lighter; text-decoration: line-through;">F</span> p fontMetrics $14 = { xHeight = 9, superscriptOffset = 128, subscriptOffset = 2, strikeoutSize = 90, strikeoutOffset = 75, underlineSize = 1, underlineOffset = -1, height = -4.6537358003282691e+129, ... } The size and offset of the strike covers all the characters (so they look as black boxes). For comparison without the font-weight the metrics are correct: data:text/html,<span style="font-family: sans; text-decoration: line-through;">F</span> p fontMetrics $13 = { xHeight = 9, superscriptOffset = 8, subscriptOffset = 2, strikeoutSize = 1, strikeoutOffset = 4, underlineSize = 1, underlineOffset = -1, height = -4.6537358003282691e+129, ... } My sans font is DejaVu LGC Sans (DejaVuLGCSans.ttf) with pango 1.18.3

Might be an issue with the font (font-weight: lighter; is using DejaVuSansExtraLight on my system): http://permalink.gmane.org/gmane.comp.fonts.dejavu/3419

Looks like a font issue to me. The best work-around might be to add these lines to /etc/fonts/local.conf or ~/.fonts.conf <selectfont> <rejectfont> <pattern> <patelt name="fullname"><string>DejaVu Sans ExtraLight</string></patelt> <patelt name="fontversion"><int>144179</int></patelt> </pattern> </rejectfont> </selectfont> fc-match -v "DejaVu Sans:weight=0" to check the fontversion.

Why doesn't it occur in FF2? Should it be reported to the distros?

(In reply to comment #14) > Why doesn't it occur in FF2? Because it didn't use Pango for the strikeout offset/size computation. > Should it be reported to the distros? I've asked on the mailing list about this issue. If this is fixed upstream the distros will be able to update their dejavu packages. In the meanwhile, you can use Karl's work-around.

The font has been fixed: http://permalink.gmane.org/gmane.comp.fonts.dejavu/3423 I guess it will take some times until this is published in the next dejavu release and all distributions have updated.

This doesn't seem like a browser code issue - it was cause (and fixed) by a 3rd party font. -> WORKSFORME