1901865 - HTML input elements use "MS Shell Dlg 2" instead of default font

Status: NEW

(Core :: Widget: Win32, defect, P3)

Description

[Tim Giles [:tgiles]]

This may be a Core :: Widget Win32 bug, but I'd figure we can start here at least. For context, this was discovered when I was working on aligning the moz-checkbox element. :mstriemer and I noticed that the alignment was off between the label text of moz-checkbox on Windows, but not on Mac. After some further investigation, we discovered that HTML inputs have a font-family of "MS Shell Dlg 2", presumably because of this LookAndFeel code. Since we're using lh units in calculating the margin for the checkbox element itself, in order to center it with the label, the "MS Shell Dlg 2" font (in my case, this resolves to "Tahoma") causes misalignment with the default or root font-family font (Times New Roman in my case). For example, in the previous Storybook case, the default font-family that gets used on Windows is "Segoe UI" but the input element's font-family resolves to "MS Shell Dlg 2" which is "Tahoma".

The workaround is to add font-family: inherit to input elements, but maybe we should do this to all HTML inputs. I wonder what the reason was for setting the input font to "MS Shell Dlg 2". I'm presuming it has something to do with internationalization or localization, but I never ran into this virtual font before. According to this Microsoft learn document:

Windows solves this problem by using the MS Shell Dlg and MS Shell Dlg 2 logical fonts to allow selection of the appropriate font for script display. This section addresses several programming considerations for using the logical fonts to implement dialog boxes, menus, and the like for flexible user interfaces that display well on all supported Windows operating systems and across all languages.

So maybe this is a WONTFIX because the HTML inputs should support all languages even if the user has set a default in Firefox (which may not be compatible with all languages, or something, trying to figure out this case).

Comment 1

[Emilio Cobos Álvarez (:emilio)]

The font is from here. That maps to here which was added here in bug 1123654.

That used to include the Dialog font and a couple others, but no longer does. Bug 1194055 seems to indicate there might be compat requirements here for <input> and <textarea>?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Maybe these days our form control layout / windows fonts don't cause that bug tho.