1. set the font size to Extra Large 2. go to http://soccernet.espn.go.com/match?id=334191&cc=5901 Expected: text is inflated Actual: no text is inflated Note: Samsung Galaxy S II; Beta Tinderbox build (from 6/12/2012)

The problem with this site is that all of those little boxes have constrained height, so the algorithm can't inflate them, since that would change the height. I don't think there's anything we can do about this in the current architecture. We probably wouldn't be able to do anything with it, even with reflow-on-zoom, since it requires the same constraint.

(In reply to Scott Johnson (:jwir3) from comment #1) > We probably wouldn't be able to do anything with it, even with > reflow-on-zoom, since it requires the same constraint. I feel like we can break this constraint in reflow-on-zoom. With reflow-on-zoom the point is to make a particular chunk of text easily readable, even if it means sacrificing the author's intended layout of the page temporarily (i.e. when you zoom out or adjust zoom again, you restore the original layout). The current blackberry browser actually does a pretty good job of this - when you zoom-to-block, it will reflow that block to wrap within the screen width, and then any subsequent zoom changes will undo that change.

(In reply to Kartikaya Gupta (:kats) from comment #2) > (In reply to Scott Johnson (:jwir3) from comment #1) > > We probably wouldn't be able to do anything with it, even with > > reflow-on-zoom, since it requires the same constraint. > > I feel like we can break this constraint in reflow-on-zoom. With > reflow-on-zoom the point is to make a particular chunk of text easily > readable, even if it means sacrificing the author's intended layout of the > page temporarily (i.e. when you zoom out or adjust zoom again, you restore > the original layout). The current blackberry browser actually does a pretty > good job of this - when you zoom-to-block, it will reflow that block to wrap > within the screen width, and then any subsequent zoom changes will undo that > change. dbaron and I have talked about this in the past. There are a couple of ways to handle this. Opera, for example, seems to reflow the lines within containers, but not the containers themselves. What we were thinking we'd do is reflow the entire page, not just the block that's been zoomed in to read. This seems to be the best alternative to prevent crazy layout problems as soon as the user pans after zooming. However, it does mean that we'd need to maintain the constrained height caveat - otherwise, we might completely mess up layout, and it's difficult to tell in which situations this would be acceptable. So, I guess my response would be "maybe we could do this." :) It's going to take a bit of messing around to determine whether we can do this or not.

Fair enough. (In reply to Scott Johnson (:jwir3) from comment #3) > This seems to be the best alternative to prevent crazy layout problems as > soon as the user pans after zooming. There are other ways to mitigate this problem as well. For example, we could make the rest of the page opacity: 0.5 except for the block that the user is reading. That way it is more apparent to the user that they are in a "special mode" where they can read that block, and the rest of the page is not meant to be interacted with. That way even if there are layout problems they won't care so much about them, as long as they know how to get out of the "special mode".

(In reply to Kartikaya Gupta (:kats) from comment #4) > There are other ways to mitigate this problem as well. For example, we could > make the rest of the page opacity: 0.5 except for the block that the user is > reading. That way it is more apparent to the user that they are in a > "special mode" where they can read that block, and the rest of the page is > not meant to be interacted with. That way even if there are layout problems > they won't care so much about them, as long as they know how to get out of > the "special mode". Ah, interesting. I hadn't thought about that. We could do something like that, and it might get around some of these issues. Good idea. We should definitely look into this.

This is a table issue, so at the very least, it's going to have to wait until bug 707195 has a solution.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.