<input> is too wide in nightly57.0a1 on Windows10 Japanese Edition

NEW
Unassigned

Status

()

Core
Layout: Form Controls
P3
normal
8 months ago
7 months ago

People

(Reporter: Alice0775 White, Unassigned)

Tracking

57 Branch
Unspecified
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox55 unaffected, firefox56 unaffected, firefox57 affected, firefox58 affected)

Details

(Whiteboard: [parity-Chrome][parity-Edge])

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

8 months ago
Created attachment 8902125 [details]
screenshot

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
(Reporter)

Updated

8 months ago
Whiteboard: [parity-Chrome][parity-Edge]
(Reporter)

Updated

8 months ago
Blocks: 548311
(Reporter)

Updated

8 months ago
Blocks: 1354004
(Reporter)

Comment 1

8 months ago
Created attachment 8902133 [details]
testcase html
(Reporter)

Updated

8 months ago
Summary: <input> is too wide in nightly57.0a1 → <input> is too wide in nightly57.0a1 on Windows10 Japanese Edition
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?
(Reporter)

Comment 3

8 months ago
Created attachment 8902138 [details]
testcase html
(Reporter)

Comment 4

8 months ago
Created attachment 8902141 [details]
screenshot of testcase html

Nightly57.0a1 : approx 22 chars
Beta56.0b6    : approx 12 chars

It is too wide in Nightly57.0a1.
Attachment #8902133 - Attachment is obsolete: true
(Reporter)

Comment 5

8 months ago
The width of the span element does not differ greatly between nightly and release.
However, the width of the input element is doubled....
why?
(Reporter)

Comment 6

8 months ago
Created attachment 8902166 [details]
testcase 2
(Reporter)

Comment 8

8 months ago
Created attachment 8902175 [details]
testcase 3 html, font specified on ancestor


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

Updated

7 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.