Closed Bug 461734 Opened 16 years ago Closed 2 years ago

Input text controls too long when using size="N" (and CJK fonts?)

Categories

(Core :: Graphics, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ryanli, Unassigned)

References

(Depends on 1 open bug, )

Details

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092903 Mandriva/1.9.0.3-1mdv2009.0 (2009.0) Firefox/3.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092903 Mandriva/1.9.0.3-1mdv2009.0 (2009.0) Firefox/3.0.3

Input text controls too long, causing the pages to look awful.

Reproducible: Always

Steps to Reproduce:
1. Go to the link given
Actual Results:  
Very very long text control.

Expected Results:  
Should be shorter.
This happens whenever and only when the "size" property of an input control is set and the CSS property "width" is not set.
As for google.com, the "size" property is set to 55, while for bugzilla.mozilla.org, the "size" property is set to 30, they both look too long.
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

Looks normal to me (useful length).
Attached image Snapshot
This only happens in Mandriva, maybe only in 2009.0, both via Live CD or installed. Mine also looks fine under Ubuntu 8.04, 8.10 and Windows XP & Vista. Snapshot of ill-rendered control is attached.
Attachment #344878 - Attachment description: Illustration → Snapshot
Ryan, can you try the following on your Mandriva system?

data:text/html,<input size="5" style="font-family: monospace" value="12345">

data:text/html,<input size="5" style="font-family: serif" value="12345">

I'd love to see snapshots of those.  I'd also be interested in a screenshot of a control with size="5" and 5 CJK characters in it.
Thanks Boris, it seems that it's a problem with CJK characters. And I wonder that if other CJK users encounter the same problem.
Possible...  Does it depend on what your default font is for whatever the relevant encoding for the page is?  Is there a particular font or set of fonts that triggers this behavior?

CJK characters are double-width, of course, but I thought we used a non-CJK character as the basis for the size="N" measurement...
Status: UNCONFIRMED → NEW
Component: Layout: Form Controls → GFX: Gtk
Ever confirmed: true
QA Contact: layout.form-controls → gtk
Summary: Input text controls too long → Input text controls too long when using size="N" (and CJK fonts?)
No, we use the maxAdvance in nsTextControlFrame::CalcIntrinsicSize.
I thought we had gfx code to force that to be equal to the aveCharWidth for monospace fonts (precisely because of issues like CJK chars and 1.5-width chars that some monospace fonts have).
I tested and found that it has nothing to do with encodings and fonts, and pretty sure it's linked with locale settings. I've changed my firefox locale to zh-CN(was en-US but the interface was in Simplified Chinese) and nothing happens. So I switched my Mandriva's locale to en-US and everything work fine now. But it's still a serious problem.
The locale determines the default fonts, no?
Whatever font I set, the font used in form controls is still the same(which is really ugly) if I use zh-CN locale. Only switching the locale to fixes this problem, but I found that I cannot use my Input Method in en-US locale. So I have to suffer.
Ryan, where are you setting the font?  As a style on the input?  Or just in your preferences?  The former should work to change the font.  The latter won't, as I recall, but changing your OS preferences for fixed fonts might...

But in any case, I don't think we should have the behavior we have now...
Ryan, I assume Firefox 2 doesn't have this problem on your system, right?
Product: Core → Core Graveyard
Component: GFX: Gtk → GFX: Thebes
Product: Core Graveyard → Core
QA Contact: gtk → thebes
So, when the locale is set for Chinese and there is no language information that can be determined from the DOM or the encoding, then the language is assumed the same as the locale (bug 91190).

If the language of the page were Chinese then using the average width of Chinese characters would be sensible.

I assume the bug here is that we don't guess that the user wants to input english?  There are no characters in the text input from which to guess the language.  I guess we could try to guess the language/script of the whole document?
Depends on: 91190
(In reply to comment #15)
> I found that I cannot use my Input Method in en-US locale.

Try setting the environment variable GTK_IM_MODULE=xim.
(In reply to comment #12)
> I thought we had gfx code to force that to be equal to the aveCharWidth for
> monospace fonts (precisely because of issues like CJK chars and 1.5-width chars
> that some monospace fonts have).

There are few monospace CJK fonts.  Some are dual-width, but aveCharWidth will never be maxAdvance for those, and should not be because they are not monospace fonts.  To solve the dual-width problem, we really need font metrics for the FontGroup that depend on the language, so that aveCharWidth for Chinese language would be different from aveCharWidth for a Latin langauage (even when the same font can be used for both languages).
I'm just saying that I thought we used to have a hack that lied about one of the widths involved...  Maybe I'm on crack, and maybe we removed it.  I agree that having such a lie is not a good thing, but neither is the behavior we end up with for inputs...

Again, I'd be quite happy if gfx would expose whether a font is "monospace" (enough for our purposes here) to layout instead of comparing aveCharWidth to maxAdvance.  In the past, there was opposition to exposing that information.
I'm not convinced that this is a bug: surely there is prima facie reason to believe that a user in a Chinese locale is going to enter Chinese text in input fields?
While true, having a different size for the input than IE does breaks layouts...
I am affected by this bug, and I do not use CJK fonts or locales.
I use Firefox under Ubuntu 12.04 "Precise Pangolin".
I did a research, and I probably know what causes this bug, just the following:

1. Firefox uses the same approach as IE 9 does: It uses system font for input controls, including font size.
2. The default system font in Ubuntu is 11pt "Ubuntu". It is by 1pt bigger than the default system font in Windows 7, which is 10pt "MS Shell Dlg". And mainly, the "Ubuntu" font seems to have a very wide metrics, because when the font used is just "Ubuntu", then the text field is much longer than it should be, and the length is exactly the same in Google Chrome (too long).

But Google Chrome uses just "Arial", probably 10pt, as the default for input controls, in both Ubuntu and Windows 7.

One strange thing is that while the "Arial" font in Ubuntu looks the same in Google Chrome and Firefox, the input text control in Firefox is longer, but only a little. In Windows, it is ok, the length is the same.

I think that it would be better if Firefox would use Google Chrome's approach to the default font of inputs controls, as:

1. Google Chrome is now much more widespread than IE.
2. IE does not have to be solving this problem of breaking layouts in different operating systems, because people normally use it only in Windows.

If the metrics of the "Ubuntu" font are somehow wrong, as it seems, then the developers of the font should fix it. I do not use the latest version of Ubuntu OS, Ubuntu 12.04 was released 1.5 years ago. It is possible that that font is fixed in the latest version of Ubuntu OS.

I made the following workaround that fixes it for me:

1. Locate your Firefox profile.
2. Create subfolder "chrome" in it, if it does not already exist.
3. Create file "userContent.css" in that "chrome" folder.
4. Add the following line of code to the new file:
input { font: normal 10pt Arial, sans-serif; }
5. Restart Firefox.
6. From now on, Firefox will use Google Chrome's approach to the default font of controls. This works well in Windows too.

Hello I have tried to reproduce the issue with firefox 96.0a1(2021-11-23), 94.0.1 and 95.0b9 on Ubuntu 20, unfortunately I wasn't able to reproduce the issue.

Marking this issue as RESOLVED-WORKSFORME since the issue is not reproducible with the latest firefox versions. If the issue is still valid please feel free to reopen it or file another bug.

Thank you!

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: