Previously, text input controls weren't font inflation containers simply by
virtue of being "display:inline" by default, which automatically makes them in-
eligible for becoming an inflation container.
As of bug 1539469 this has changed however - those <input> elements are now
"display:inline-block" by default, which with the current font inflation logic
turns them into font inflation containers.
This leads to a few problems:
1. The logic from bug 708175 (stop inflation if there is a size-constrained non-
inline frame in the chain from the current frame to their font inflation
container) is built on the assumption that the (possibly size-constrained)
form control itself isn't a font inflation container.
2. When form controls end up as font inflation containers themselves, they no
longer size themselves properly to match the size of their inflated
contents, because they are now subject to the AutoMaybeDisableFontInflation/
mInflationDisabledForShrinkWrap logic which ends up disabling font inflation
during the size calculation of the form control.
1.) means that we now inflate some text inputs that we didn't use to inflate
previously and 2.) means that every time we attempt to inflate a text input, we
end up with the text content being inflated, but the containig box being not and
therefore too small.
Because of this, as well as because
1. The introductory comment in nsFrame::IsFontSizeInflationContainer itself
mentions that form controls aren't expected to be inflation containers.
2. There is the precedent from bug 786946, where <select> elements were
specifically excluded from becoming font inflation containers when their
default display style was changed from "inline" to "inline-block".
all of this points towards having to specifically preclude <input> elements
from becoming font inflation containers as well.
Differential Revision: https://phabricator.services.mozilla.com/D64908
--HG--
extra : moz-landing-system : lando
