Last Comment Bug 707195 - Text inflation inflates comments on news.ycombinator.com to different sizes (because inflation computed separately for different table cells)
: Text inflation inflates comments on news.ycombinator.com to different sizes (...
Status: ASSIGNED
[font-inflation: nested tables][reada...
: productwanted, uiwanted
Product: Core
Classification: Components
Component: Layout (show other bugs)
: unspecified
: ARM Android
: P2 normal with 24 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors: David Baron :dbaron: ⌚️UTC-10
: 707725 748026 752983 769175 769863 826744 857164 1090166 1135699 (view as bug list)
Depends on: 756518 706193 747720 825516
Blocks: 730603 747267 757257 763957 font-inflation 738240
  Show dependency treegraph
 
Reported: 2011-12-02 09:02 PST by Patrick Walton (:pcwalton)
Modified: 2015-02-23 08:28 PST (History)
57 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
+


Attachments
Screenshot of the behavior (46.21 KB, image/png)
2011-12-08 10:01 PST, Scott Johnson (:jwir3)
no flags Details
screenshots (3.93 MB, application/x-zip-compressed)
2012-06-01 06:13 PDT, Cristian Nicolae (:xti)
no flags Details
Screenshot hg.mozilla.org pushloghtml (209.09 KB, image/png)
2012-08-06 11:44 PDT, Thomas Stache
no flags Details

Description Patrick Walton (:pcwalton) 2011-12-02 09:02:38 PST
On comments on news.ycombinator.com, comments get inflated to different sizes depending on their nesting depth, resulting in bizarre output. Hacker News uses nested <table> elements to render comments.
Comment 1 David Baron :dbaron: ⌚️UTC-10 2011-12-07 14:37:38 PST
*** Bug 707725 has been marked as a duplicate of this bug. ***
Comment 2 David Baron :dbaron: ⌚️UTC-10 2011-12-07 14:40:04 PST
This might just well be expected behavior for sites like this.  I think iOS Safari may well do the same thing here.  Or does it somehow manage to do better?  (We could do better if we could determine which blocks were part of the same flow and which weren't, but I don't know any decent heuristic for that.)
Comment 3 Sam Tobin-Hochstadt [:samth] 2011-12-07 14:42:48 PST
I just looked at this on an iPhone, and while it happens some there, it's not nearly as bad.  Fewer comments are shrunk, and they're shrunk by less.
Comment 4 Scott Johnson (:jwir3) 2011-12-08 10:01:32 PST
Created attachment 580084 [details]
Screenshot of the behavior

This screenshot is on an HTC evo 4g, with Nightly from 12-7-11.
Comment 5 Scott Johnson (:jwir3) 2011-12-08 11:49:47 PST
(In reply to David Baron [:dbaron] from comment #2)
> This might just well be expected behavior for sites like this.  I think iOS
> Safari may well do the same thing here.  Or does it somehow manage to do
> better?  (We could do better if we could determine which blocks were part of
> the same flow and which weren't, but I don't know any decent heuristic for
> that.)

Hmm.. well, could we take the outermost <table> element and somehow scale the font size to the largest available of all its children? So, for example, if we had:

<table>
<tr>
<td>
Some text 1
</td>
<td>
  <table>
  <tr>
  <td>Some text 2.
  </td>
  </tr>
  </table>
</td>
</tr>
</table>

If we found an appropriate size to inflate the "some text 2" text at, could we bound "some text 1" by that, so that it can inflate to no greater than that size? 

It would require a two-pass solution, though, since we'd have to figure out the font inflation size of all of a frame's children before we could set the font inflation size for that frame.
Comment 6 David Baron :dbaron: ⌚️UTC-10 2011-12-08 20:28:53 PST
The problem is that it's hard to distinguish that case from the (probably more common) case where the outer table doesn't have any text in it and the inner table does have text in it.  In that case, we want the inflation to be based on the inner table.
Comment 7 Emanuel Hoogeveen [:ehoogeveen] 2011-12-10 03:24:38 PST
Isn't that the case that Scott was talking about? That is, he proposed the text in the outer table (Some text 1) be bounded (from above) by the text in the inner table (Some text 2.), if I'm reading his comment right.
Comment 8 Emanuel Hoogeveen [:ehoogeveen] 2011-12-10 03:30:41 PST
Ah, I should clarify, I mean that regardless of whether there's any text in the outer table, what he proposed would not impose any (additional) limits on text in the inner table.
Comment 9 JP Rosevear [:jpr] 2012-02-23 19:27:25 PST
Beta blockers.
Comment 10 David Baron :dbaron: ⌚️UTC-10 2012-03-02 16:07:01 PST
I thought I had a plan for fixing this in bug 706193 comment 13, but I don't think it's going to work.  I think this should not be a beta blocker, and should perhaps even be wontfix.
Comment 11 David Baron :dbaron: ⌚️UTC-10 2012-03-02 16:21:04 PST
Actually, I think I can make it work by only considering the widths of things that are ancestors of the first piece of text -- I think that should be sufficient, and we know those.
Comment 12 Scott Johnson (:jwir3) 2012-03-20 09:22:02 PDT
Reassigning to dbaron, since he's attacking this in combination with bug 706193.
Comment 13 Scott Johnson (:jwir3) 2012-04-11 10:14:04 PDT
dbaron, 

blassey asked for status on this bug during the mobile engineering meeting today. I said you told me that this likely won't be worth fixing, but I just wanted to ping you for an update in the bug, in the event that something has changed since last we spoke.
Comment 14 David Baron :dbaron: ⌚️UTC-10 2012-04-12 15:50:10 PDT
This was previously blocking-fennec1.0: beta+.  I'm renominating with the suggestion that we punt on this bug for now and minus it.

I tried to fix this as part of work on bug 706193, but I couldn't find a reasonable way around the basic chicken-and-egg problem:  to fix this we'd want to know the widths of the containers of all the text, which requires doing layout on the whole subtree (or at least a decent part of it), but we need to know the inflation numbers before we do layout.  (It's probably doable by constructing reflow states for the entire subtree as we walk it, but that would be a significant performance hit that I don't think we want to take.)

For the record, the point where I gave up was https://hg.mozilla.org/users/dbaron_mozilla.com/patches/rev/3b2eb3585f6a

I'd also note that at least based on my memory, I think iOS Safari has similar behavior on this site, though comment 3 notes that our differentiation is more drastic.
Comment 15 Sam Tobin-Hochstadt [:samth] 2012-04-12 15:59:39 PDT
(In reply to David Baron [:dbaron] from comment #14)
> This was previously blocking-fennec1.0: beta+.  I'm renominating with the
> suggestion that we punt on this bug for now and minus it.
>
> I'd also note that at least based on my memory, I think iOS Safari has
> similar behavior on this site, though comment 3 notes that our
> differentiation is more drastic.

I read HN a lot on my phone, and this bug makes it a pretty poor experience.  Somewhere between 1 in 5 and 1 in 10 comments are unreadable.  The iOS Safari experience is very different -- you can tell there's a bug, but every comment is readable.
Comment 16 Brad Lassey [:blassey] (use needinfo?) 2012-04-16 13:12:53 PDT
dbaron, we talked through a strategy for fixing this a few weeks ago. What has changed since then?
Comment 17 David Baron :dbaron: ⌚️UTC-10 2012-04-16 16:08:08 PDT
I tried doing it, and couldn't figure out how (see comment 14).

(Once display list based invalidation lands, we can probably make some architectural changes to Reflow that would make this easier, though.)
Comment 18 David Mandelin [:dmandelin] 2012-04-23 10:41:38 PDT
I see very similar behavior on the headlines on reddit.com. (Also see http://reddit.com/r/TrueReddit) Desktop and Opera Mobile both display it correctly.
Comment 19 Brad Lassey [:blassey] (use needinfo?) 2012-04-25 12:06:34 PDT
*** Bug 748446 has been marked as a duplicate of this bug. ***
Comment 20 David Baron :dbaron: ⌚️UTC-10 2012-04-25 13:49:51 PDT
An easier way to fix this just occurred to me,  I think:  just use the ncaWidth that we compute in the nsFontInflationData for the width (and thus mostly get rid of the idea of a font inflation container).
Comment 21 David Baron :dbaron: ⌚️UTC-10 2012-04-26 13:25:57 PDT
Actually, that would likely fix reddit, but it wouldn't fix ycombinator since ycombinator is using a separate table for each comment.
Comment 22 JP Rosevear [:jpr] 2012-04-27 05:22:25 PDT
Can we do the reddit fix and then continue on with ycombinator as a separate bug?
Comment 23 David Baron :dbaron: ⌚️UTC-10 2012-04-27 09:44:03 PDT
I have a set of patches, but it doesn't fix reddit either.  Not sure where to put it.  It's possible it might be useful as progress towards a fix, but I'm skeptical.  (Need to debug reddit a bit, but for some reason the inspector devtool mysteriously stopped working for me, so I need to figure out how to get it working again to do so.)

There's a danger to trying to tweak this continuously.  What font inflation is is a set of heuristics to (a) figure out what text forms a coherent chunk and ought to be treated together and (b) to figure out which pieces of text are safe to be inflated without breaking the page.  Any changes to these heuristics to fix one page have a risk of breaking another page, and they (being heuristics) are never going to be perfect.  At some point we have to stop tweaking and either decide that we want the feature as a whole or we don't want it; I'd like to know when that's going to be.  (If we don't want it, an alternative is implementing Android-browser-style zooming that reflows on rewrap.)

I'd also note that (from memory, it's been a little while since I've done this testing, but perhaps somebody could verify) other mobile browsers don't do particularly well on this sort of page either.  My memory is that, on news.ycombinator.com comment pages:
 * iOS Safari (which also uses a font inflation approach) limits its inflation and thus preserves the visual appearance better but also doesn't actually inflate the text enough so that it's readable, which thus means that scrolling side-to-side for each line is needed (at least with the device in portait mode)
 * Opera mobile does a bit better, but still requires (as we do) resetting of context for reading each comment (not as bad as for each line), though in Opera mobile's case the context the user has to change is only horizontal panning rather than panning and zooming
 * Android native browser (on my Android devices, anyway) does nothing at all to make the text readable, and it requires scrolling side-to-side for each line.  (On some Android versions or devices the Android native browser takes a zooming approach like what I see on Opera mobile, but I haven't actually seen that in action for ages, since I don't have such a device/version.)
Comment 24 David Baron :dbaron: ⌚️UTC-10 2012-04-27 14:54:59 PDT
(The reason we don't inflate reddit at all, by the way, is that we detect it as a mobile site because of its <meta name="viewport" content="width=1024" />, which leads to nsContentUtils::GetViewportInfo returning a value that has defaultZoom set to 1.0, which in turn means that nsLayoutUtils::FontSizeInflationEnabled returns false.)
Comment 25 David Baron :dbaron: ⌚️UTC-10 2012-04-27 15:04:57 PDT
And the reason the patches wouldn't fix reddit even without the <meta viewport> is reddit's use of overflow:hidden/overflow:auto in a bunch of places, which creates an inflation flow root.  Now, I think I could change things so that overflow:hidden / overflow:auto don't make something an inflation flow root, except I remember dealing with that case when working on bug 706193, so I think either (a) there was some technical issue that made that necessary to avoid crashing or (b) one of the sites that was fixed by bug 706193 depended on making overflow!=visible make something an inflation flow root.

For the record, the patches I'm testing are:
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/a54e29a0bbb6/save-nca-width
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/a54e29a0bbb6/change-to-auto-disable-for-shrink-wrap
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/a54e29a0bbb6/use-constant-width
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/a54e29a0bbb6/fix-list-control-frame
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/a54e29a0bbb6/remove-width-determination
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/a54e29a0bbb6/remove-current-inflation-container
and they might be a useful simplification anyway.
Comment 26 Mark Finkle (:mfinkle) (use needinfo?) 2012-05-01 12:20:16 PDT
Madhava, Ian: We're interested in your thoughts on this issue.
Comment 27 Ian Barlow (:ibarlow) 2012-05-01 12:45:23 PDT
From a UX perspective, we should really try to fix this somehow. Reddit and ycombinator look terrible in our browser right now. Some examples:

ycombinator http://cl.ly/0l2f2v0p3v0e290J0A0W

Reddit http://cl.ly/1M452m2a2D3D04070S1I

These pages look perfectly fine in stock Browser -- they are a little wonky in Chrome but still better than us.
Comment 28 Naoki Hirata :nhirata (please use needinfo instead of cc) 2012-05-07 09:47:02 PDT
*** Bug 748026 has been marked as a duplicate of this bug. ***
Comment 29 Aaron Train [:aaronmt] 2012-05-08 07:11:41 PDT
*** Bug 752429 has been marked as a duplicate of this bug. ***
Comment 30 n.t.koopman 2012-05-17 08:26:06 PDT
(In reply to David Baron [:dbaron] from comment #23)
> I'd also note that (from memory, it's been a little while since I've done
> this testing, but perhaps somebody could verify) other mobile browsers don't
> do particularly well on this sort of page either. 

So, from this post I assume that text inflation is not standardised? Maybe getting some input from other vendors would be a good idea before this turns into another endless source of frustration for designers.
Comment 31 David Baron :dbaron: ⌚️UTC-10 2012-05-17 12:56:00 PDT
(In reply to Tim from comment #30)
> So, from this post I assume that text inflation is not standardised? Maybe
> getting some input from other vendors would be a good idea before this turns
> into another endless source of frustration for designers.

I've started trying to do this; see http://dev.w3.org/csswg/css-size-adjust/ .  However, so far Apple hasn't provided feedback.  (And I also haven't had a chance to update it to changes I've made recently.)
Comment 32 David Baron :dbaron: ⌚️UTC-10 2012-05-18 07:51:40 PDT
(In reply to David Baron [:dbaron] from comment #25)
> And the reason the patches wouldn't fix reddit even without the <meta
> viewport> is reddit's use of overflow:hidden/overflow:auto in a bunch of
> places, which creates an inflation flow root.  Now, I think I could change
> things so that overflow:hidden / overflow:auto don't make something an
> inflation flow root, except I remember dealing with that case when working
> on bug 706193, so I think either (a) there was some technical issue that
> made that necessary to avoid crashing or (b) one of the sites that was fixed
> by bug 706193 depended on making overflow!=visible make something an
> inflation flow root.

It turns out to be (b) -- removing this breaks http://www.nytimes.com/ again (the original problem in bug 706193), though probably most of the other things fixed by bug 706193 are still fixed.
Comment 33 David Baron :dbaron: ⌚️UTC-10 2012-05-18 11:33:53 PDT
(In reply to David Baron [:dbaron] from comment #32)
> (In reply to David Baron [:dbaron] from comment #25)
> > And the reason the patches wouldn't fix reddit even without the <meta
> > viewport> is reddit's use of overflow:hidden/overflow:auto in a bunch of
> > places, which creates an inflation flow root.  Now, I think I could change
> > things so that overflow:hidden / overflow:auto don't make something an
> > inflation flow root, except I remember dealing with that case when working
> > on bug 706193, so I think either (a) there was some technical issue that
> > made that necessary to avoid crashing or (b) one of the sites that was fixed
> > by bug 706193 depended on making overflow!=visible make something an
> > inflation flow root.
> 
> It turns out to be (b) -- removing this breaks http://www.nytimes.com/ again
> (the original problem in bug 706193), though probably most of the other
> things fixed by bug 706193 are still fixed.

Er, oops, I was testing in a build with a non-default lineThreshold pref.  It actually seems fine.
Comment 34 David Baron :dbaron: ⌚️UTC-10 2012-05-18 12:02:31 PDT
I'm going to put the first phase of work for this bug in bug 747720, since that's the first dependency I found that's entirely fixed by that first phase.  (I think reddit also would be, if it weren't for bug 756518.)
Comment 35 David Baron :dbaron: ⌚️UTC-10 2012-05-21 16:02:19 PDT
So, the basic thing with tables is that we want:
 (a) data tables *not* to make inflation flow roots
 (b) layout tables used for indentation *not* to make inflation flow roots (required to fix this bug)
 (c) layout tables used as grids to make their cells inflation flow roots (required not to break http://www.nytimes.com/)

The question is how to find a way to distinguish case (c) from cases (a) and (b) that:
 (1) is accurate enough
 (2) doesn't involve too many heuristics that make it hard for authors to understand the behavior
 (3) doesn't cause too many cases where a tiny change to the page can cause the result to change

I'm still thinking about whether it's better to start from the assumption that we do want to make cells flow roots and look for cases where we shouldn't, or the other way around.
Comment 36 David Baron :dbaron: ⌚️UTC-10 2012-05-25 09:24:57 PDT
So I have a patch that fixes this while simultaneously not breaking bug 706193.  However, it uses a complicated condition that feels to me like it's just fixing a single site, and I think it's a bad idea to complicate the Web platform to fix a single site rather than to fix a real pattern.

I've made a set of three test builds to allow others to test this.  They vary in when they consider table cells to be a barrier for scoping the region in which we make font size inflation decisions.

The first build is equivalent to a mozilla-central build from a few days ago (in particular, based on https://hg.mozilla.org/mozilla-central/rev/8cf563a575fd) and always considers table cells to be a barrier:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dbaron@mozilla.com-869b1a345058/

The second build uses the complicated condition that fixes this bug while not breaking bug 706193:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dbaron@mozilla.com-b53b151c3f00/

The third build changes to *never* considers table cells to be a barrier, which fixes this bug *and* breaks bug 706193:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dbaron@mozilla.com-d4cc4ac5c1c7/

So what I'd like to know is:
 (a) where do the first and third builds produce different behavior?  (So far, the only two sites I know of are ycombinator.com comments and the nytimes.com homepage)
 (b) in each of those cases, which of the first and third build is better, and does the second build go with the better option?

Obvious places to look for things to test are dependencies/blockers of this bug, bug 706193, and bug 747720, but perhaps any other readibility bugs.
Comment 37 David Baron :dbaron: ⌚️UTC-10 2012-05-25 09:26:49 PDT
And I'd note that it may be easier to test using the desktop builds by setting the font.size.inflation.emPerLine preference to some number in the range 10-20 than by typing lots of urls on the Android builds.
Comment 38 David Baron :dbaron: ⌚️UTC-10 2012-05-25 10:07:49 PDT
And one further note:  any bug where builds one and three don't make a difference should not be a dependency of this bug.
Comment 39 Jet Villegas (:jet) 2012-05-29 15:39:57 PDT
Re-nomming this one to force a re-test against the posted builds.
Comment 40 Cristian Nicolae (:xti) 2012-06-01 06:13:59 PDT
Created attachment 629163 [details]
screenshots

Build 1

    Bugzilla: font inflation issue is noticeable for the text on the Search button and for the text above the Search input field. Rotating the device to landscape will not resolve the issue and it still persist if the device is switched back to portrait.
    Google News: the main news frame covers the entire screen when the page is loaded for the 1st time and if the page is panned, bug 747720 is easy noticeable for some news entries. The left and right frames are not displayed at all. If the device is switched to landscape and then back to portrait, the font inflation issues seems to be fixed.
    NYTimes: the webpage looks fine both in portrait in landscape. If the page orientation is changed, no changes will occur regarding the font inflation.
    YouTube: the main frame which contain the videos list, looks really bad. Text is hyper inflated and rotating the device, will not fix the issue. It seems to be permanent, like for the Bugzilla case.


Build 2

    Bugzilla: font is inflated much more than the 1st build. If the device orientation is switched to landscape and back to portrait, will not resolve the font inflation issue.
    Google News: all 3 frames are displayed even from the 1st page load. The text from the main frame is a little bit more inflated than the side frames, but it looks OK. If the page is switched to landscape and then back to portrait, the text from the main frame seems to be smaller than it was just after the page was loaded, and also quite the same level as it on the left and right frame. So the Google News will look perfect in this case if the white space between the main frame and the right one will be reduced.
    NYTimes: the font seems to be a little bit less inflated than it is on the 1st build, but the difference is barely noticeable. The webpage looks fine
    YouTube: there is the same result as for the 1st build.


Build 3

    Bugzilla: the font seems to be even more inflated than it is for the first 2 builds. Again, there are no changes if the device orientation is switched to landscape and back to portrait.
    Google News: there are no words to describe how bad this page looks when it's loaded for the 1st time (see attached screenshots for build 3). After the device rotation, the font inflation issue still persist and the page still look really bad,
    NYTimes: the page's footer is highly inflated and also the Inside NYTimes.com section look horrible (we have to mention that the page cannot be panned on that side and things might be complicated when that section covers the entire screen)
    YouTube: there is the same result as for the 1st build.


Conclusions:

- Build 3 is far the worst test build.
- Build 2 is better then the 1st one, because of the good layout shapes for Google News and NYTimes, but none of them could even candidate for the final release in our opinion
- Bugzilla and YouTube pages looks awful on all 3 test builds, but as David said in bug 707195 c#36, a real pattern should be fixed, instead of fixing individual websites
Comment 41 David Baron :dbaron: ⌚️UTC-10 2012-06-04 17:46:12 PDT
So the summary of that is that so far we have 4 sites where builds (1) and (3) are known to differ:

                           build           build          build
                            (1)             (2)            (3)
ycombinator comments        BAD             good           good
nytimes.com                 good            good           BAD
Google News                  ?               ?             BAD
Bugzilla                     ?               ?              ?

(? marks are for where I can't tell from comment 40 which builds produce better results)


So so far that provides no evidence that the compromise in build (2) applies any more broadly than the two sites for which the condition was designed (ycombinator comments and nytimes.com).

But per discussion in the triage meeting today, more testing is in progress.
Comment 43 Aaron Train [:aaronmt] 2012-06-05 07:39:27 PDT
Some additional gatherings — albeit a bit inconclusive, I have ran through a variety of varied top-sites by country which serve desktop-optimized content across all posted builds. The content served has markup which is not greatly affected by the font-inflation heuristics tweaked in each build with the exception of some greatly noticeable differences in Bugzilla and Y Combinator and Drudge Report. 

http://people.mozilla.com/~atrain/mobile/Evangelism/font-inflation-compare/
Comment 44 Mark Finkle (:mfinkle) (use needinfo?) 2012-06-05 07:42:16 PDT
(In reply to Aaron Train [:aaronmt] from comment #43)
> Some additional gatherings — albeit a bit inconclusive, I have ran through a
> variety of varied top-sites by country which serve desktop-optimized content
> across all posted builds. The content served has markup which is not greatly
> affected by the font-inflation heuristics tweaked in each build with the
> exception of some greatly noticeable differences in Bugzilla and Y
> Combinator and Drudge Report. 
> 
> http://people.mozilla.com/~atrain/mobile/Evangelism/font-inflation-compare/

And I think only Bugzilla is negatively affected. Y-Combinator and Drudge Report are more readable with the inflation.
Comment 45 Matt Brubeck (:mbrubeck) 2012-06-29 18:18:54 PDT
*** Bug 769863 has been marked as a duplicate of this bug. ***
Comment 46 Tony Chung [:tchung] 2012-07-09 09:29:27 PDT
removing qawanted tag, as comment 40 provided testing.  re-nom the qawanted if there's more test builds you'd like investigation on.
Comment 47 Erin Lancaster [:elan] 2012-07-25 14:09:00 PDT
*** Bug 752983 has been marked as a duplicate of this bug. ***
Comment 48 Jet Villegas (:jet) 2012-07-25 14:18:35 PDT
P2 per font inflation scrub.
Comment 49 Scott Johnson (:jwir3) 2012-07-25 16:40:24 PDT
*** Bug 769175 has been marked as a duplicate of this bug. ***
Comment 50 Oliver Henshaw 2012-07-27 09:38:17 PDT
Apologies if I'm stating the obvious, since I can't see this explicitly mentioned: don't the tiny comments on ycombinator tend to be the shorter ones? i.e. the different sizes have more to do with the length of the comment than the nesting depth. This pattern holds for e.g. phoronix.com forums and guardian comments (bug 752429), neither of which have nested threads (and the guardian comments page uses floats not tables).

Take http://news.ycombinator.com/item?id=4291084 as a recent example. I see shrunken comments at all nesting levels. Additionally, take the direct link to this comment: http://news.ycombinator.com/item?id=4293161 which at the time of posting has no replies so there's only one level of nesting, and it's still shrunken and hard to read without zooming in.

So based on my inexpert reading of http://dev.w3.org/csswg/css-size-adjust/ isn't the problem with comments too short to trigger text inflation?
Comment 51 Scott Johnson (:jwir3) 2012-07-27 11:10:11 PDT
(In reply to Oliver Henshaw from comment #50)
> Apologies if I'm stating the obvious, since I can't see this explicitly
> mentioned: don't the tiny comments on ycombinator tend to be the shorter
> ones? i.e. the different sizes have more to do with the length of the
> comment than the nesting depth. This pattern holds for e.g. phoronix.com
> forums and guardian comments (bug 752429), neither of which have nested
> threads (and the guardian comments page uses floats not tables).
> 
> Take http://news.ycombinator.com/item?id=4291084 as a recent example. I see
> shrunken comments at all nesting levels. Additionally, take the direct link
> to this comment: http://news.ycombinator.com/item?id=4293161 which at the
> time of posting has no replies so there's only one level of nesting, and
> it's still shrunken and hard to read without zooming in.
> 
> So based on my inexpert reading of http://dev.w3.org/csswg/css-size-adjust/
> isn't the problem with comments too short to trigger text inflation?

Oliver:

Yes, you're correct. It has to do with table cells being assigned as font-inflation "flow roots", which is what we call a node in the frame tree where font inflation data aggregation begins. So, in other words, what's happening is that at each table cell, we're making a decision about how much text is underneath the given flow root and determining whether we should inflate based on this. Unfortunately, since every table cell is a flow root, it means that we're restarting aggregation of font inflation data for each table cell, when we should be doing it for the whole set of comments in total. 

The real crux of the issue, though, is that this is ONLY the case for situations where tables are being used for layout with respect to positioning - if a table is being used for representing tabular data, or to create a grid-like layout (as in the nytimes.com case), then we still want table cells to be marked as flow roots. We can't distinguish between these cases readily enough, because our system isn't designed to treat these two cases differently. We need to come up with an heuristic that allows us to distinguish these two cases.
Comment 52 Thomas Stache 2012-08-06 11:44:42 PDT
Created attachment 649331 [details]
Screenshot hg.mozilla.org pushloghtml

jwir3 asked me to provide this screenshot of http://hg.mozilla.org/mozilla-central/pushloghtml 
This site also suffers from the separate inflation roots for individual table cells, although this page uses tables for tabular data, not presentation.
Comment 53 Scott Johnson (:jwir3) 2012-08-06 12:53:26 PDT
(In reply to Thomas Stache from comment #52)
> Created attachment 649331 [details]
> Screenshot hg.mozilla.org pushloghtml
> 
> jwir3 asked me to provide this screenshot of
> http://hg.mozilla.org/mozilla-central/pushloghtml 
> This site also suffers from the separate inflation roots for individual
> table cells, although this page uses tables for tabular data, not
> presentation.

Thanks, Thomas!
Comment 54 dggrr 2012-08-30 06:05:14 PDT
This also seems to apply to anything based on Simple Machines Forum software.

See http://www.simplemachines.org/community/index.php?topic=483398.0 as an example

This page displays fine on a Firfox desktop but some items have tiny text using Android ARM on my HTC One V (ICS) or Nexus 7 (Jelly Bean).
Comment 55 Tomer Cohen :tomer 2012-10-17 10:24:14 PDT
(In reply to dggrr from comment #54)
> This also seems to apply to anything based on Simple Machines Forum software.
Default phpBB3 theme as well (prosilver), and I think I've also seen it on Slashdot.
Comment 56 tnleeuw 2012-11-21 00:34:02 PST
Some of my most frequented online forums suffer from this bug; they are indeed phpBB based so I guess that posting more URLs doesn't make sense but this defect is for me probably the biggest reason why I'm not using more FireFox on Android.

The Android native browser and Dolphin (which uses the native browser engine) do not suffer from this same problem (at least not visibly to my eye!).

I have also never observed this issue on desktop.
Comment 57 Hervé Renault 2012-12-30 10:07:45 PST
I'm new to Firefox for Android, as I own an ARMv6 mobile, and in my opinion this is the biggest problem. It makes a lot of pages barely readable.
(That's too bad because, for the rest, I love having Sync in my pocket)
Comment 58 Scott Johnson (:jwir3) 2013-02-10 14:42:45 PST
*** Bug 826744 has been marked as a duplicate of this bug. ***
Comment 59 Aaron Train [:aaronmt] 2013-04-02 10:16:02 PDT
*** Bug 857164 has been marked as a duplicate of this bug. ***
Comment 60 Sepero 2013-04-16 18:52:36 PDT
I submitted this bug before and it was marked as a dup in this thread. I just wanted to give a big thanks to everyone working hard to fix this. Everything you're doing is appreciated. David, Patrick, Sam, Scott, Emanuel, Brad, JP, Ian, Jet, Christian, Aaron, Tony, Oliver, and anyone I might have missed. Thank you
Comment 61 Frederik Niedernolte 2013-08-07 08:42:34 PDT
For me every page mentioned works and is displayed as it should. 
To achieve that I have set the font size to tiny and enabled fit text size after zoom. 
I have additionally set browser.viewport.defaultZoom pref to 1000 in about:config
Try it out!
Comment 62 Alexander Wunschik 2013-11-13 06:57:16 PST
I had a similar problem with Firefox 25.0 on a Nexus 7. 
Setting "-moz-text-size-adjust: none;" in the CSS does the trick for me!
Comment 63 Paolo Montrasio 2014-07-18 00:20:11 PDT
Thank you Alexander for that CSS rule. I added it to my pages and Firefox handles them in a saner way.

However any other browser handles font inflation in a better way by default. This is my biggest complaint about FF on Android. To make developers understand how important it is, this is the reason why I don't use FF on Android even if it is my primary desktop browser and this is the reason why I won't neither consider nor recomment a Firefox OS phone: basically I'm sure that a Firefox OS phone can't be used to browse the web.

Nevertheless, thanks for trying but please find a solution.
Comment 64 Eugene Savitsky 2014-08-20 00:08:50 PDT
One of a most annoying "features". Example:
http://www.overclockers.ru/hardnews/63102/Vypuskat_planshety_stanovitsya_vse_menee_vygodno.html
Comment 65 Eugene Savitsky 2014-08-20 00:13:38 PDT
(In reply to Eugene Savitsky from comment #64)
> One of a most annoying "features". Example:
> http://www.overclockers.ru/hardnews/63102/
> Vypuskat_planshety_stanovitsya_vse_menee_vygodno.html

In the comments area at the bottom.
Comment 66 Aaron Train [:aaronmt] 2014-10-28 07:09:18 PDT
*** Bug 1090166 has been marked as a duplicate of this bug. ***
Comment 67 Aaron Train [:aaronmt] 2015-02-23 08:28:27 PST
*** Bug 1135699 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.