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)
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.
Updated•16 years ago
|
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Comment 2•16 years ago
|
||
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).
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
Comment 5•16 years ago
|
||
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.
Comment 10•16 years ago
|
||
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.
Comment 12•16 years ago
|
||
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).
Reporter | ||
Comment 13•16 years ago
|
||
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.
Comment 14•16 years ago
|
||
The locale determines the default fonts, no?
Reporter | ||
Comment 15•16 years ago
|
||
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.
Comment 16•16 years ago
|
||
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...
Comment 17•16 years ago
|
||
Ryan, I assume Firefox 2 doesn't have this problem on your system, right?
Assignee | ||
Updated•15 years ago
|
Product: Core → Core Graveyard
Updated•15 years ago
|
Component: GFX: Gtk → GFX: Thebes
Product: Core Graveyard → Core
QA Contact: gtk → thebes
Comment 18•15 years ago
|
||
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
Comment 19•15 years ago
|
||
(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.
Comment 20•15 years ago
|
||
(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).
Comment 21•15 years ago
|
||
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.
Comment 22•15 years ago
|
||
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?
Comment 23•15 years ago
|
||
While true, having a different size for the input than IE does breaks layouts...
Comment 24•11 years ago
|
||
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.
Comment 25•2 years ago
|
||
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.
Description
•