415715 - Any (?) element with line-through and font-weight: lighter displays as black box

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

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.

Comment 1

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Minimal HTML page exhibiting the problem

Comment 2

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

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.

Comment 3

[[:Cww]]

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

Comment 4

[Sylvain Pasche]

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?

Comment 5

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Screenshot displaying the display of previous attachment

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.

Comment 6

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

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?

Comment 7

[Sylvain Pasche]

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.

Comment 8

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

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?

Comment 9

[Sylvain Pasche]

> 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).

Comment 10

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: HTML page more reliably exhibiting the problem

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.

Comment 11

[Sylvain Pasche]

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

Comment 12

[Sylvain Pasche]

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

Comment 13

[Karl Tomlinson (:karlt)]

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.

Comment 14

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

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

Comment 15

[Sylvain Pasche]

(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.

Comment 16

[Sylvain Pasche]

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.

Comment 17

[Jason Bassford]

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

-> WORKSFORME