748054 - default font.size.inflation.lineThreshold value causing inconsistent font inflation

Status: RESOLVED DUPLICATE of bug 747267

(Core :: Layout, defect)

Description

[Damon Sicore (:damons)]

Attachment: Screenshot showing inconsistent font sizes.

I'm running a custom build containing a mishmash of fixes (FX 14.0a1, 4-20-2012), but this problem has appeared on all nightlies I've tried over the past 5-6 weeks.  Brad asked I file this just in case it's different from the other font inflation issues.

STR:

1) Visit http://damon.sicore.com

Expected results:  All fonts are the same size as specified.

Actual:  Some fonts appear larger than the rest.

See screenshot.


Could be a duplicate of bug 748026.

Comment 1

[JP Rosevear [:jpr]]

I'm seeing "Error: RSS file not found, dude. Username invalid or requires authentication�" when loading the site right now.

Comment 2

[Scott Johnson (:jwir3)]

This has to do with the font.size.inflation.lineThreshold value that was added as part of bug 706193. In about:config, if you change font.size.inflation.lineThreshold to 0, then the fonts are inflated consistently. 

This value controls the "threshold" of text needed before enabling font inflation. It's a percentage that is the approximate number of lines needed before triggering font inflation. "Approximate" because it assumes that each character has the width of a single em-size of the font, but this is actually smaller on average.

Basically, it means that a value of 100 for font.size.inflation.lineThreshold means that we need the equivalent of one line of characters of em-sized width before font inflation will be enabled. By default, this is 400, which means we need on four lines of em-sized width characters before font inflation engages. 

This value *might* be able to be adjusted, but it's a balancing act. If we lower this threshold, then we run the risk of inflating things like the nytimes.com footer text that was being inflated too much in bug 706193.

Comment 3

[Scott Johnson (:jwir3)]

So, something that dbaron and I talked about on Tuesday was that we might be able to fix this if we can determine why individual table cells are being chosen as flow roots, rather than something higher up in the frame tree, and whether or not we can easily correct this. I'm currently exploring this option now.

Comment 4

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

Fixing ycombinator (bug 707195) would require the patch series I've already written in that bug, possibly plus patches to make overflow!=visible (i.e., nsHTMLScrollFrame) not be an inflation flow root (which is what should fix reddit), plus patches to make *some* table cells not be inflation flow roots (but leave others, otherwise we'd regress nytimes.com).  I think the underlying heuristic could perhaps be something like whether there's inflatable text in more than one column of the table, but figuring out the right way to do that and how to do it efficiently is likely to be tricky.

Comment 5

[Scott Johnson (:jwir3)]

Interestingly, I'm not seeing this issue anymore on latest trunk (with this site at least, but the problem does probably still exist in a more general form).

Comment 6

[Scott Johnson (:jwir3)]

(In reply to Scott Johnson (:jwir3) from comment #5)
> Interestingly, I'm not seeing this issue anymore on latest trunk (with this
> site at least, but the problem does probably still exist in a more general
> form).

Oops, this was a debugging patch that I had pushed. I think it solved the issue, but only because I was forcing font inflation to be enabled in nsFontInflationData.cpp. Disregard my previous comment. ;)

Comment 7

[Scott Johnson (:jwir3)]

This is the same behavior as is being exhibited in 747267. Basically, we're looking at tables that have the cells as flow roots, when the table itself should be a flow root. I'll post the relevant data to that particular bug, so it's not lost.