Closed Bug 385510 Opened 18 years ago Closed 17 years ago

HTML <textarea> on trunk has less width than col= attribute states

Categories

(Core :: Graphics, defect, P5)

x86
Linux
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: kairo, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files, 1 obsolete file)

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/2007062101 SeaMonkey/2.0a1pre On my local home page, I have a HTML <textarea name="notes" rows="10" cols="65"> for taking quick notes. While on branch, 65 characters can be shown in its width (actually it even allows 66), trunk only shows 49 characters of width. I have a comparison screenshot available, but I think I'll do a reduced testcase and attach that and a screen shot of that instead of my local page.
And here's a comparison screenshot of 1.8 branch and my current trunk build.
Sorry, I just realized I had a different default font set for the normal text surrounding the form inputs when taking the trunk screenshot (Vera vs. Arial). Now both screen shots are taken with fonts set to the same sizes of the same fonts (Arial for sans-serif/default, Vera Sans Mono for Monospace).
Attachment #269429 - Attachment is obsolete: true
Keywords: regression, testcase
From bug 388179 comment #0: Boris Zbarsky 2007-07-14 14:07:10 PDT This is the pango equivalent of bug 364300. I'm seeing the max-advance end up twice as big as the ave char width, due to CJK chars. I wouldn't be surprised if Windows has a similar issue...
Component: Layout: Form Controls → GFX: Thebes
QA Contact: layout.form-controls → thebes
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
this seems to go away for me with the patch in 399813. can anyone else verify?
i can't reproduce this with or without my patch. Can anyone actually still reproduce this?
Priority: P3 → P5
Actually, you're right, it looks OK now... and I don't even know when it got fixed. The textarea seems correctly sized in the testcase now, the input looks a bit too short though, but I guess that's bug 399813 as you mentioned.
Status: NEW → RESOLVED
Closed: 17 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: