Closed Bug 434718 Opened 16 years ago Closed 16 years ago

em-based font-size wrong when minimum font size set


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

Not set





(Reporter: oschoett, Unassigned)




(Keywords: dev-doc-complete, regression, testcase)


(7 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080313 SeaMonkey/1.1.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

FF3 RC1: font-size in em units is wrong when minimum font size is set.  The resulting font is much smaller than in FF2.

Reproducible: Always

Steps to Reproduce:
1. Set minimum font size 14 pt.
2. Visit with JavaScript enabled.
3. Select font-size: other, 1.2 em
Actual Results:  
Result with FF3 RC1: left text sample stays approx. the same size as the others

Expected Results:  
Result with FF2: left text sample becomes clearly larger than the others.

This appears to be correct.

The problem can be seen on other web pages as well that set font-size in em units.
(Unfortunately, the sample page I have is internal, so I would welcome if people could add public pages that exhibit the bug).
Attached image FF2 rendering (OK)
Confirmed on Linux, version
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008052213 (Gentoo) Firefox/3.0
(compiled on Gentoo)

Added keyword "regression", as it is a regression from FF2
Keywords: regression

shows the bug very cleary: the FF2 rendering is correct, as the first highlighted paragraph obtains a font-size of roughly 1.5 * 0.8 times the size of the surrounding text.

In FF3 this paragraph is hardly enlarged at all.

It appears that the minimum font size setting is not taken into account when computing the size of an em, which is badly broken.

Screenshots will be enclosed from Windows XP
Severity: normal → major
OS: Windows XP → All
I think this problem should be looked at before FF3 breaks website layouts all over the place -> candidate for blocking FF3
Flags: blocking-firefox3?
Not a blocker, would take a deemed-safe fix for 3.0.1; re-componentizing for better visibility by the right people.
Severity: major → normal
Component: General → Layout: Fonts and Text
Flags: wanted1.9.0.x?
Flags: in-testsuite?
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Version: unspecified → Trunk
Fixing it in 3.0.1 means that there will be layout differences between FF 2.0 and 3.0 and between FF 3.0 and 3.0.1.  This will not go down well with website authors.
Attachment #322757 - Attachment description: bigbear with FF2 on XP, 120dpi screen: first highlighted paragraph not enlarged = incorrect → bigbear with FF3 on XP, 120dpi screen: first highlighted paragraph not enlarged = incorrect
The attachment em_problem_demo.html shows that the em and ex units no longer take the minimum font size into account as they used to in FF2.  When the minimum font size exceeds the font size desired by the web page, this leads to completely different dimensions everywhere these units are used.
Severity: normal → major
Summary: em-based font-size wrong when minimum font size set → em, ex units no longer take minimum font size into account (regression from FF2)
Layout can always be affected by user preferences, such as custom stylesheets, underline/colour-link preferences, or minimum font sizes, of course.

Web site authors do not need to concern themselves with 3.0 once 3.0.1 has been out for a month or so -- our users upgrade very aggressively, and 3.0.1 will be released before we offer a major update to our current FF2 users.  We can put a note in the release notes for FF3.0 to which webmasters can direct users who complain about the difference in rendering, when they have this preference set.

But we can't fix it in 3.0.1 without a patch, so if you want to help with that I would recommend trying older builds of FF3 betas and alphas to find out when the regression occurred.  Thanks for your help!
Severity: major → normal
Keywords: relnote, testcase
Summary: em, ex units no longer take minimum font size into account (regression from FF2) → em-based font-size wrong when minimum font size set
(This bug is not "major"; please read the descriptions at  It's also already marked as a regression via the keyword.  Thanks!)
Ever confirmed: true
Sorry, my mistake: leaving out the em-based font-size settings from the previous demo, it can be seen that the difference in the em,ex units is just a consequence of the different ways the font-size is handled between FF2 and FF3
The attachment shows that the new behaviour is probably a feature rather than a bug:  The percentage-based font scaling behaves the same in FF2 and FF3, resulting in a font that is the same size as the original font.

The em-based font scaling, however, "bounces" off the minimum font size in FF2, that is, the minimum font size affects further em-based scaling.

The new behaviour in FF3 can be summarized as follows: there is an "intended font size", which is used for calculating relative font sizes using percentages or em or ex units, and which is not affected by the minimum font size. Also, there is an "actual font size" bounded by the minimum font size, which controls the rendering of fonts and the ex,em units when not used in font-size.

In other words, the ex,em units in font-size are based on the "intended font size", in other cases they are based on the "actual font size".  When used to control font-size, these units now behave the same way as percentages in FF3.

As a bug this may therefore be regarded as invalid.  It is still a change that web designers must look out for.

I'm going to mark this INVALID, as you suggest, but I also wanted to thank you for your great analysis here.  Would you consider adding it to the documentation at to help other web developers?
Closed: 16 years ago
Flags: wanted1.9.0.x?
Flags: in-testsuite?
Keywords: dev-doc-needed
Resolution: --- → INVALID
By default there's no minimum font size, so 99% of users won't have minimums and I doubt most Web developers care about them.

Because of that, the FF3 approach is better for users who do use minimum font sizes, because it makes fewer elements have sizes that are different to the no-minimum-size case.
I don't think this is a major enough issue to relnote, but yes, we should add it to the documentation.
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.