Firefox logged one warning per glyph, on every page load, for every Font Awesome file WeKan serves:

downloadable font: glyf: Glyph bbox was incorrect; adjusting (glyph 19)
(font-family: "Font Awesome 6 Free" ...) source: .../fa-regular-400.woff2

819 of the 2163 glyphs were affected - 540 in fa-solid-900, 204 in fa-brands-400, 59 in fa-regular-400, 16 in fa-v4compatibility - so the console filled with hundreds of lines and stopped being useful for spotting anything else.

Every TrueType glyph stores its own bounding box in the glyf table. Font Awesome ships boxes that are TIGHTER than the outline: they bound the on-curve points only, while the box has to bound the control points too, because a quadratic curve can bulge past its endpoints. Firefox’s OpenType sanitiser notices, corrects each box in memory and says so. Nothing rendered wrongly - the warning was the whole of the damage - but the numbers in the file were wrong, and they are wrong upstream, in Font Awesome’s own build.

releases/fix-font-bboxes.py recomputes them, and writes the .ttf and the .woff2 from one corrected font so the pair cannot drift. Only head and hhea differ from what Font Awesome shipped, and both follow from the boxes; every other table compiles identically, which the script verifies by reading back what it wrote. It keeps Font Awesome’s own head.modified, so two runs over the same input agree byte for byte rather than churning a committed binary.

tests/fontGlyphBounds.test.cjs parses the fonts with its own reader rather than the tool that wrote them, and that guard matters more than the fix: these fonts are VENDORED, so the next Font Awesome upgrade drops fresh upstream files straight back into the tree and the warnings would return silently, months from anything that would explain them. The failure message names the script to re-run.