Closed Bug 354497 Opened 18 years ago Closed 13 years ago

For each character typed on a line in a textarea, the caret gets more and more out of position

Categories

(Core :: DOM: Editor, defect)

1.9.0 Branch
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: sheppy, Unassigned)

References

Details

Attachments

(2 files)

As you type in a textarea in Firefox, the caret gradually creeps toward the left of where it should be, pixel by pixel, until eventually it's to the left of the character you're typing.  As you then delete and backspace on the line, you wind up with the cursor flashing in totally the wrong place, which makes editing extremely difficult (especially for guys like me trying to edit the docs in a wiki).

I'll be attaching some screenshots momentarily.
The caret is flashing after the "t" in "with" even though I've already typed the "h", which you can only see a smidgeon of because it didn't draw correctly.
Summary: On each line in a textarea, the caret gets more and more out of position → For each character typed on a line in a textarea, the caret gets more and more out of position
Can you reproduce this in, say, the Bugzilla comment textarea or is this problem only reproducible on the wiki?
Component: General → Editor
Product: Firefox → Core
QA Contact: general
Version: 2.0 Branch → 1.8 Branch
Which builds are you seeing this in?
This happens on any web site with textareas, in every version of Firefox I've ever used.  Particularly all 1.5 builds from 1.5 to 1.5.0.7, and all builds of Firefox 2.

I just happened to use MDC as an example in this case.
Just noting that this still happens for me in the release build of Firefox 2, on all five Macs in my house.
I just spent a few minutes trying different fonts and sizes for the non-proportional font setting, and have some useful information.

I use 13 as my default font size, instead of the default 16.  This appears to be the cause of the problem.  If I use Courier 10 or 12, the cursor moves properly.  At 13, it exhibits this gradual falling-behind behavior.

Monaco works fine at all of these sizes, on the other hand.
I've just noticed that similarly, when you set the font and size to Times 13, certain web sites exhibit formatting problems.  One prime example is http://www.macintouch.com, where the text following links in the document isn't spaced properly, such that the first couple of letters of the following word overlaps the end of the link.
I experienced this very same problem in a plaintext compose window in a 1.5.0.7 thunderbird build on osx.

My profile was migrated from an ancient profile in linux that had gone through multiple thunderbird versions.

Through whatever process I don't understand, the monospace font had been set to the first in the list.. some 'Abadi MT Condensed Extra B...' (it's name is truncated, I have no idea what it is.).  I tried 13 and 12 points and both of those exhibited the problem.

When I switched to Monoco and 12 points the problem stopped and the cursor positioning works as expected.

I have also seen the formatting problems that are mentioned in comment 8, though in my case it came from viewing a mail message that had email addresses embedded in it.  Like:

Foo Dude <foo@dudes.com>

When rendered the email address would overlap the end of the real name.

When the mail is rendered with Monoco the overlapping stops.
Yeah, this problem seems to happen with some sizes regardless of how you're configured.  As sites do plusses and minuses off the base font size, eventually they hit combinations that cause this to happen.  Nothing I do eradicates it completely.  It happens both in textareas and in the main body of sites, depending totally on the font and size combinations that occur.
Here's another testcase for this bug (using Bitstream Vera Sans Mono). (On the other hand, I don't mean to contribute toward bugspam, so I apologize if that's the case.)

1. Download the Bitsteam Vera font family:
http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/ttf-bitstream-vera-1.10.zip

2. Install the fonts to your system.

3. Under Preferences -> Content, choose "Advanced" in the "Fonts & Colors" section

4. Set the "Monospace" pull-down to "Bitstream Vera Sans Mono" (and leave it on the default size, 13)

5. Then, after setting that, you can see this bug occur by adding and deleting some text in a bug's comment field (such as for this bug).

(I've been able to confirm this testcase with this BuildID: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070103 BonEcho/2.0.0.2pre)
QA Contact: editor
Just to put it on record, since it's not been mentioned, this problem doesn't exist in Firefox 3 builds.
This sounds very much like it was a symptom of bug 377104, though I haven't heard confirmation (or denial) that that bug is gone in Gecko 1.9.
I tested with several different font sizes. The text renders correctly with monospace font courier size set to 10, 12, or 14 on my system. 

With monospace font size set to 9, 11, 13, 15, 16, or 17 the text width does not appear to render correctly. Letters in monospaced fonts will overlap nearby text. Highlighting does not work correctly. Cursor position is set incorrectly. Deleting text within a text entry field will leave a jumble of incorrectly rendered pixels. 

I did not test with sizes larger than 17 points.

(I tested on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7)
I found this same bug when composing emails in Thunderbird 2.0.0.6, in text areas in Camino 1.6a1pre and Firefox 2.0.0.9.  On Mac OS X 10.4.11.

In Thunderbird, fixed it by changing the font to Times, it works in all sizes.  Also works in all sizes with Courier.  The default variable width font does not work in "medium" or "small" sizes, but works fine in the other font sizes.  The default fixed width font does not work in small, medium or large font sizes, but in the other sizes it does.  When set to Helvetica/Arial, doesn't work in small or medium sizes, but works in the other sizes.
According to comment 18, this has been fixed in Firefox 3.
Status: NEW → RESOLVED
Closed: 13 years ago
OS: Mac OS X → All
Hardware: PowerPC → All
Resolution: --- → FIXED
Version: 1.8 Branch → 1.9.0 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: