Steps To Reproduce: 0. Windows10 home 64bit CU, Japanese Edition 1. Open https://docs.python.org/2/library/abc.html Actual Results: See attached screenshot

Well, the causes of this difference with Edge and Chrome are different. Edge treats the generic font family, "sans-serif", not as "Meiryo". Actually, ASCII characters are not displayed with Meiryo, but Japanese characters are displayed with Meiryo. So, if you change the font-family of the <input> to "Meiryo" or "メイリオ", you can see same result. So, the generic font family handling is different from Gecko. On the other hand, Chrome behaves odd. Even if you change the font-family to "Meiryo" or "メイリオ", you don't see wider <input> element but the <input> element is displayed with Meiryo. So, the behavior is really odd to me. Chrome might not use Meiryo's metrics to compute <input> element size. I guess this may not be so major problem since this is caused by incomplete style rules. If web designers change font of <input>, they should specify <input> element size with CSS rather than using size attribute or not specifying anything for avoiding too long/short <input> element. On the other hand, if we could change <input size> computation or default size of <input>, we may have avoided this issue forever. However, it may cause other issues like too short <input> element for specific fonts. This issue might have been discussed in other bugs, but I don't know that. Any ideas?

Nightly57.0a1 : approx 22 chars Beta56.0b6 : approx 12 chars It is too wide in Nightly57.0a1.

The width of the span element does not differ greatly between nightly and release. However, the width of the input element is doubled.... why?

The width is computed with average character width of the font that is stored in font metrics, not actual width: https://searchfox.org/mozilla-central/rev/cd82cacec2cf734768827ff85ba2dba90a534c5e/layout/forms/nsTextControlFrame.cpp#141,157,161-162 And the default size attribute value of Gecko is 20: https://searchfox.org/mozilla-central/rev/cd82cacec2cf734768827ff85ba2dba90a534c5e/dom/html/nsITextControlElement.h#218

This seems to be as expected if font specified on ancestor element.

(In reply to Alice0775 White from comment #8) > This seems to be as expected if font specified on ancestor element. Yes, web designers need to specify font-family to <input> directly since we specify it directly in default stylesheet. Therefore, this should not be so major. https://searchfox.org/mozilla-central/rev/cd82cacec2cf734768827ff85ba2dba90a534c5e/layout/style/res/forms.css#89,98

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)