With today's nightly, on my Samsung Galaxy SII the headlines on fark.com are inflated to all different sizes. One and two line headlines are tiny; longer headlines are readable. Looks very strange. I expect this to get duped to an existing bug.

filter on [mass-p5]

Happening here also on firefox for android: http://foroafeitado.com/foro/maquinillas-tradicionales-cuchillas-29/personna-platinum-mercadona-las-mismas-8720/index2.html

Is there any way I can add Linux as affected platform? I originally filed a bug about FF for Linux, but it was marked as a duplicate of this report which is limited to Android.

(In reply to Clemens Eisserer from comment #7) > Is there any way I can add Linux as affected platform? > I originally filed a bug about FF for Linux, but it was marked as a > duplicate of this report which is limited to Android. The underlying renderer is the same; I don't think this is platform specific. The bug is filed in Core :: Layout, but I changed the platform to All just in case.

What we're missing is what Chrome calls "fingerprinting" in this document: https://docs.google.com/document/d/1PPcEwAhXJJ1TQShor29KWB17KJJq7UJOM34oHwYP3Zg/ I.e. translating this into our own terminology: For each font inflation flow root, we'd have to also compute a fingerprint based on a few relevant properties. Then, if for a given fingerprint there is at least one font inflation flow root with enough text to actually trigger font inflation, we'll enable font inflation for *all* flow roots sharing the same fingerprint. [1] The data that goes into the fingerprint needs to be carefully chosen so that the bits that are problematic today [2] share a common fingerprint and get inflated together, while at the same time correctly tagging things that should remain uninflated with a different fingerprint. [1] Actually Chrome goes a step further and also ensures a common font size multiplier (presumably for things like pages with nested/indented comments), but an initial implementation might get away without doing that. This would also be one more argument to do what I suggested in bug 1493266 and completely move the MinimumFontSizeFor() calculations into the calculation of the FontInflationData instead of partially calculating it on the fly - I think this should make it easier to then ensure a common font size factor across all flow roots sharing a fingerprint. [2] Forum threads, comment areas, Bugzilla bugs :-) and similar pages, where the content we care about for font inflation is divided into lots of separate bits (and therefore covered by separate font inflation flow roots) and where some of those bits are short enough to individually fall below the font inflation threshold.