50.63 KB, image/png
5.54 KB, image/png
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.
Created attachment 240315 [details] I've already typed the "h" on "with" but you can't see it. 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.
Created attachment 240316 [details] Here I just typed the letter "l" in "all", but the cursor is to its left.
Can you reproduce this in, say, the Bugzilla comment textarea or is this problem only reproducible on the wiki?
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 22.214.171.124, 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 126.96.36.199 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 <email@example.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:188.8.131.52pre) Gecko/20070103 BonEcho/184.108.40.206pre)
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:220.127.116.11) Gecko/20070914 Firefox/18.104.22.168)
I found this same bug when composing emails in Thunderbird 22.214.171.124, in text areas in Camino 1.6a1pre and Firefox 126.96.36.199. 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.