Bug 1540176 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Daniel Holbert [:dholbert] from comment #2)
> Note that font inflation is disabled by default (since bug 1127441) because it's not clear it's a net win, as described in that bug.

Though we might take the opportunity of the GeckoView-based rewrite to have another go at re-enabling it.

(In reply to Daniel Holbert [:dholbert] from comment #4)
> (It might also be pretty easy to fix this bug, so feel free to try your hand at that instead, if you'd like. :)  But, it's probably not a particularly important thing to do.)

This is just guessing based on what I can remember from looking at font inflation last year, and I didn't have the opportunity to actually look at what's happening, so the following may be completely off the mark (but hopefully it isn't):
1. Originally, "font inflation containers" [1] were the smallest layout unit the font inflation operates on, i.e. for which font inflation can be turned off. This is to ensure that frames that are closely related are always inflated together, i.e. all or nothing. Apart from a few special cases, basically any non-inline frame (including `inline-block`) will be a font inflation container.
2. Through bug 708175 however, which [introduced](https://hg.mozilla.org/integration/mozilla-inbound/rev/1587faab5e5c) that reftest in question, we gained some code ([the code today](https://dxr.mozilla.org/mozilla-central/rev/04bd7929b499d25fc538e516fc3de1aa6e9d79dc/layout/base/nsLayoutUtils.cpp#8061-8093)) that can turn off inflation for certain frames *inside* a font inflation container.
3. Therefore my guess would be that because those inputs elements have become `inline-block`, they are now font inflation containers in their own right and hence the original logic no longer applies to them.4
4. Therefore, if I'm not mistaken (dbaron might be able to correct me if I'm talking nonsense), [this function] now needs to be adapted to detect and handle this particular case.



[1] Scott Johnson wrote an article about how it works. [This archived link](https://web.archive.org/web/20140730170810/http://www.jwir3.com/blog/2012/07/30/font-inflation-fennec-and-you/) has working footnotes, but only small images (the big versions weren't archived at that time), whereas the [live version](https://www.jwir3.com/font-inflation-fennec-and-you/) has the full-res images available, but broken footnotes.
(In reply to Daniel Holbert [:dholbert] from comment #2)
> Note that font inflation is disabled by default (since bug 1127441) because it's not clear it's a net win, as described in that bug.

Though we might take the opportunity of the GeckoView-based rewrite to have another go at re-enabling it.

(In reply to Daniel Holbert [:dholbert] from comment #4)
> (It might also be pretty easy to fix this bug, so feel free to try your hand at that instead, if you'd like. :)  But, it's probably not a particularly important thing to do.)

This is just guessing based on what I can remember from looking at font inflation last year, and I didn't have the opportunity to actually look at what's happening, so the following may be completely off the mark (but hopefully it isn't):
1. Originally, "font inflation containers" [1] were the smallest layout unit the font inflation operates on, i.e. for which font inflation can be turned off. This is to ensure that frames that are closely related are always inflated together, i.e. all or nothing. Apart from a few special cases, basically any non-inline frame (including `inline-block`) will be a font inflation container.
2. Through bug 708175 however, which [introduced](https://hg.mozilla.org/integration/mozilla-inbound/rev/1587faab5e5c) that reftest in question, we gained some code ([the code today](https://dxr.mozilla.org/mozilla-central/rev/04bd7929b499d25fc538e516fc3de1aa6e9d79dc/layout/base/nsLayoutUtils.cpp#8061-8093)) that can turn off inflation for certain frames *inside* a font inflation container.
3. Therefore my guess would be that because those inputs elements have become `inline-block`, they are now font inflation containers in their own right and hence the original logic no longer applies to them.4
4. Therefore, if I'm not mistaken (dbaron might be able to correct me if I'm talking nonsense), [this function](https://dxr.mozilla.org/mozilla-central/rev/04bd7929b499d25fc538e516fc3de1aa6e9d79dc/layout/base/nsLayoutUtils.cpp#8137-8154) now needs to be adapted to detect and handle this particular case.



[1] Scott Johnson wrote an article about how it works. [This archived link](https://web.archive.org/web/20140730170810/http://www.jwir3.com/blog/2012/07/30/font-inflation-fennec-and-you/) has working footnotes, but only small images (the big versions weren't archived at that time), whereas the [live version](https://www.jwir3.com/font-inflation-fennec-and-you/) has the full-res images available, but broken footnotes.
(In reply to Daniel Holbert [:dholbert] from comment #2)
> Note that font inflation is disabled by default (since bug 1127441) because it's not clear it's a net win, as described in that bug.

Though we might take the opportunity of the GeckoView-based rewrite to have another go at re-enabling it.

(In reply to Daniel Holbert [:dholbert] from comment #4)
> (It might also be pretty easy to fix this bug, so feel free to try your hand at that instead, if you'd like. :)  But, it's probably not a particularly important thing to do.)

This is just guessing based on what I can remember from looking at font inflation last year, and I didn't have the opportunity to actually look at what's happening, so the following may be completely off the mark (but hopefully it isn't):
1. Originally, "font inflation containers" [1] were the smallest layout unit the font inflation operates on, i.e. for which font inflation can be turned off. This is to ensure that frames that are closely related are always inflated together, i.e. all or nothing. Apart from a few special cases, basically any non-inline frame (including `inline-block`) will be a font inflation container.
2. Through bug 708175 however, which [introduced](https://hg.mozilla.org/integration/mozilla-inbound/rev/1587faab5e5c) that reftest in question, we gained some code ([the code today](https://dxr.mozilla.org/mozilla-central/rev/04bd7929b499d25fc538e516fc3de1aa6e9d79dc/layout/base/nsLayoutUtils.cpp#8061-8093)) that can turn off inflation for certain frames *inside* a font inflation container.
3. Therefore my guess would be that because those inputs elements have become `inline-block`, they are now font inflation containers in their own right and hence the original logic no longer applies to them.
4. Therefore, if I'm not mistaken (dbaron might be able to correct me if I'm talking nonsense), [this function](https://dxr.mozilla.org/mozilla-central/rev/04bd7929b499d25fc538e516fc3de1aa6e9d79dc/layout/base/nsLayoutUtils.cpp#8137-8154) now needs to be adapted to detect and handle this particular case.



[1] Scott Johnson wrote an article about how it works. [This archived link](https://web.archive.org/web/20140730170810/http://www.jwir3.com/blog/2012/07/30/font-inflation-fennec-and-you/) has working footnotes, but only small images (the big versions weren't archived at that time), whereas the [live version](https://www.jwir3.com/font-inflation-fennec-and-you/) has the full-res images available, but broken footnotes.

Back to Bug 1540176 Comment 5