textfields are much wider in Firefox (as compared to Chrome) when using Noto CJK fonts
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
Details
(Keywords: webcompat:platform-bug)
Attachments
(3 files)
screenshot of testcase in Firefox Nightly (left) vs Chrome (right)
STR:
- Load attached testcase on Ubuntu (with
fonts-noto-cjkinstalled at least)
(the testcase uses other fonts as well; I don't recall which of them are installed by default, but they don't matter as much)
ACTUAL RESULTS:
The bottom 6 textfields are much wider than the rest (overshooting the 280px-wide orange reference-rectangle by quite a lot).
EXPECTED RESULTS:
Maybe they shouldn't be so wide? It's not clear why they are; and in Chrome, they're actually skinnier than many of the others in the testcase.
This seems to be the root cause of bug 1895999 (at least, the part of that bug that still manifests as a difference between Chrome dev 128 and Firefox, per bug 1895999 comment 5).
|
Reporter | |
Comment 1•1 year ago
|
||
|
|
Reporter | |
Comment 2•1 year ago
•
|
||
The Chrome vs. Firefox difference exists here on Android as well, but there's an additional reason there -- Chrome seems not to recognize these Noto system fonts at all on Android (i.e. it uses a fallback font), whereas Firefox does recognize them.
|
|
Reporter | |
Comment 3•1 year ago
|
||
|
|
Reporter | |
Comment 4•1 year ago
|
||
testcase 2 lets you test this bug using Google Fonts web-fonts for these Noto font-faces, so that platform font availability (from comment 2) doesn't prevent you from comparing Chrome vs. Firefox with the actual fonts.
That helps to demonstrate that this Firefox/Chrome difference does exist on all (I think?) platforms -- Android is where I'm testing right now, at least. Chrome sizes the Noto-font-face textfields as substantially skinnier than the default textfield, while Firefox sizes them as substantially wider.
|
|
Reporter | |
Comment 5•1 year ago
|
||
Interestingly, Safari 17.3 on macOS actually matches us on testcase 2. (Their rendering on testcase 1 is irrelevant since the font isn't available as a system font there, at least on the BrowserStack environment that I'm testing.)
So that suggests that Chrome's behavior on testcase 2 (making textfields skinnier, rather than wider as Safari/Firefox do) might actually be a Chrome bug or quirk...
|
||
Comment 6•1 year ago
|
||
Huh, one thing I notice is that if I add an explicit width: 20ch (for example) to the input styling, the Noto-styled inputs suddenly become slightly narrower than the one using the default font.
I guess this is a result of the various heuristics here which look at several metrics from the font to try and ensure the field is "wide enough", rather than just relying on the ch unit.
Interesting that Safari is doing exactly (or near enough) the same as Firefox here.
|
|
||
Comment 7•1 year ago
|
||
The HTML spec gives a specific algorithm to be used here:
The converting a character width to pixels algorithm returns (size-1)×avg + max, where size is the character width to convert, avg is the average character width of the primary font for the element for which the algorithm is being run, in pixels, and max is the maximum character width of that same font, also in pixels. (The element's 'letter-spacing' property does not affect the result.)
which does not entirely match what we're doing; I wonder if this comes from Blink, and what the history of the spec is.
(One issue I see with that spec text is that it doesn't appear to define "average character width of the primary font", which could be interpreted in a number of ways.)
|
|
||
Comment 8•1 year ago
|
||
Out of curiosity, I tried modifying nsTextControlFrame::CalcIntrinsicSize to directly use the algorithm from the spec, and it made only a small difference to the results we get on the testcase; we're still a long way from matching Chrome's result.
If I modify it to use the width of the 0 glyph (which is the basis of CSS ch units) as the basis for avg in the algorithm, instead of the "average character width" property from the font, it comes much closer to how Chrome behaves, though not an exact match.
I'd argue that Chrome's result with these CJK fonts is not particularly "good", anyhow; the intent of the default sizing of input textfields is that they're large enough for approximately 20 characters, but Chrome's field only fits about 11 of the CJK characters here (and it's reasonable to assume that if a CJK font is being specified, we should be primarily concerned with CJK content). But it's all very hand-wavy, and probably the major question is around the interpretation of "average character width of the font".
(The spec note that "letter-spacing does not affect the result" also seems surprising to me; that doesn't reflect Firefox behavior, though it does seem to be what Chrome does. I don't see why that would be desirable, though.)
|
|
||
Comment 9•1 year ago
|
||
FWIW, it looks like Gecko has included letter-spacing in the computation since bug 252783, so it's been 20 years....
|
|
||
Comment 10•1 year ago
|
||
I've opened https://github.com/whatwg/html/issues/10458 to ask about what the HTML spec says on this.
|
|
Reporter | |
Comment 12•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #2)
Chrome seems not to recognize these Noto system fonts at all on Android (i.e. it uses a fallback font), whereas Firefox does recognize them.
I spun off bug 1906190 for this^, BTW.
|
||
Updated•1 year ago
|
|
|
Reporter | |
Comment 13•1 year ago
|
||
(In reply to Jonathan Kew [:jfkthame] from comment #8)
(The spec note that "letter-spacing does not affect the result" also seems surprising to me; that doesn't reflect Firefox behavior, though it does seem to be what Chrome does. I don't see why that would be desirable, though.)
This behavior with the letter-spacing property is now tracked in bug 1918967, BTW.
Description
•