816070 - On FF Linux, the CSS line-height computed value is significantly off when "normal"

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect)

Description

[Martin Bouladour]

Attachment: Visual illustration of the bug

This bug seems to apply only to Firefox Linux.

In a HTML document, when the CSS property line-height of an element is not set or set to "normal" (it is the default value), then the computed value for this property on this element is not exact.

In other words, window.getComputedStyle(element)['lineHeight'] returns a value in px that when applied back to the element, changes the displayed line-height. The intuitive (and right?) behavior would be that doing this doesn't change anything.

The bug only appear when the line-height value "normal" is used.

See the attached HTML document using FF17 Linux to see the bug in action. Note that the sale factor (zoom) of the page somehow affects this behavior.

I did a few check on other browsers and OS. Here's what I found:

Firefox 17 on Fedora 17 with Gnome 3.4.1: WRONG
Firefox 17 on Windows 7: OK
Chrome 23 on Fedora 17 with Gnome 3.4.1: OK
Chrome 23 on Windows 7: OK
IE9 on Windows 7: OK

Another thing: Both Chrome and IE9 return "normal" as a computed value in that case (which I believe is OK). Only Firefox returns a value computed in px. And by the way, this contradicts the MDN documentation that recommends using unitless values for line-height (see https://developer.mozilla.org/en-US/docs/CSS/line-height ).

Comment 1

[Loic]

Do you know if the issue is present with previous versions of Firefox on Linux?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Given the zooming bit, this sounds like some sort of rounding issue...

Comment 3

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

Could you go to about:support, go to the "Important Modified Preferences" section, and tell us (copy & paste) everything that's listed there that starts with "font."?

(I'm particularly interested in whether there are differences between x-western and x-unicode.)

And what language build are you using?

Comment 4

[Martin Bouladour]

@Loic: No, I don't have any older versions of Firefox Linux installed. I use the Firefox provided by Fedora's package manager. How can I install older versions alongside my up-to-date one, without too much of a hassle ?

@David: Went to about:support's Important Modified Preferences and here are the ones that start with font:
font.name.monospace.x-western DejaVu Sans Mono
font.name.sans-serif.x-western Liberation Sans
font.name.serif.x-western Liberation Serif

I'm using the French language build.

Comment 5

[Martin Bouladour]

@Loic: In the attached example HTML file, I wrote "The bug seems to exist only using Firefox 17 Linux", but I meant to write "... Firefox Linux" (without the 17, my bad). It could be also present in previous versions. The important thing is that (according to my little testing) it doesn't affect Windows versions.

Comment 6

[Martin Bouladour]

I did a little test using different fonts installed on my Linux system.

Here is the test protocol I used (using the attached HTML document), for each font:
1. Set the font to be tested as the default font in Firefox settings;
2. Zoom in to the max using Ctrl+MouseWheel (reaching the highest value of the scale factor).
3. Reload the page so that the script that copies getComputedStyle's line-height value does its job (it executes at window's load event);
4. Visually check whether or not the blue and green divs are aligned at their bottom;
5. Decrement the scale factor, i.e. zoom out by one step using Ctrl+MouseWheel;
6. Repeat steps 3, 4 and 5 until the minimum zoom has been reached.
7. If at least once the divs where misaligned, then the bug has been seen.

The results:

Font name               Font type  Bug seen
----------------------- ---------- ---------
Liberation Sans         TTF        YES
Liberation Serif        TTF        YES
Liberation Mono         TTF        -
DejaVu Sans             TTF        YES
DejaVu Serif            TTF        YES
DejaVu Sans Mono        TTF        YES
Abyssinica SIL          TTF        -
PT Sans                 TTF        -
Linux Biolinum O        OTF        -
Linux Libertine O       OTF        -
Linux Libertine Mono O  OTF        -
Cantarell               OTF        -
STIXGeneral             OTF        -
Yanone Kaffeesatz       OTF        -
Vollkorn                OTF        -
Terminus                PCF        -
Utopia                  PFA        -
Nimbus Sans L           AFM + PFB  -
Nimbus Roman No9 L      AFM + PFB  -
Nimbus Mono L           AFM + PFB  -
URW Bookman L           AFM + PFB  -
URW Chancery L          AFM + PFB  YES
URW Gothic L            AFM + PFB  -
URW Palladio L          AFM + PFB  -
Century Schoolbook L    AFM + PFB  -


Strangely, URW Chancery L is the only font of its kind (AFM + PFB) to be affected by the bug. Note that all of the AFM+PFB fonts here are provided by the same manufacturer (URW++).

Concerning Terminus, some scale factor values were not relevant for the tests; as a bitmap font, it was replaced by a default non-bitmap font when the requested size were not available. But it hasn't prensented any misalignment for the scale factor values where it was not replaced.

FWIW, my conclusion is that True Type fonts (TTF) create a mess, while Open Type fonts (OTF) behave nicely.

I hope this data will help.