When editing text in the mail component or in this field, actually, The visual cursor position gets farther and farther away from it's actual text editing position the farther to the left the text extends... This happens with most text, but not all.. Some webpages with specially formatted text allows me to highlight text and not have it jump around,but most of the time, when I hightlight text, it tends to jump to the visual position of the cursor breaking up the text.. I don't know if anyone else is having this problem, but it really makes editing text with any mozilla based browser very difficult. I'm using Mac Os X (10.1.5) and this happens with both Mozilla1.2 and Netscape7.0.

resembles bug 128394

I did not see this problem with 1.21 on OS X. Upon installing 1.3b, it is a plague.

Israel, can you still reproduce this problem using a current nightly build? If so, can you reproduce this problem using another Mozilla user profile? If yes to both, what is the font face of the text are you editing? Please attach a screenshot.

related bug: Bug 178735 cursor movement in textarea broken again (broken on Solaris)

*** This bug has been marked as a duplicate of 188288 ***

Is it really a dupe of 188288? On Mac OS X, CTL has never been turned on as far as I know. Has it been turned on in 1.2? If not, this should be reopened.

Israel, would you please try reproduce this again on the current build, thank you. I'll reopen this one. btw, does the Mac OS X version share any CTL-related source with a UNIX version?

Sounds similar to bug #119860

Israel, does this problem still occur in Mozilla 1.7 or newer?

I see this issue. Was not a problem with Firefox 0.90, but cropped up again in Firefox 0.93. Removing profiles directory and starting from scratch did not resolve issue. System: OS X 10.3.5 with all updates (up to 09/07/2004 security update) Firefox 0.93

I'm getting this as well on OS X 10.4 (Tiger) with Firefox 1.0.4. I also experienced it on OS X 10.3.9 with 1.0.3, and earlier versions that I can't specifically remember. The cursor position problem seems to occur with text input controls whose font is set to certain variable width fonts such as Arial or Verdana. It gets worse the farther into the text field you go, and seems to depend on there being spaces in the text. I'm thinking there's a chance it's related to Bug #292461. I'll attach a test case with screen shots. One live example is http://souceforge.net, which defaults to small Arial for all it's textareas. Entering a bug or making a forum post is near impossible without preparing it in a text editor first and pasting in the final draft. This is a big hit to usability for Firefox on OS X and I think this bug should be upgraded to Severity=major. I'm experiencing the text moving while highlighting problem as well. That's a little harder to show with screen shots, but I'll attach two that if you compare closely show how the characters are shifting around slightly. I'm also getting a graphics corruption when backspacing over text in the test case. I'll attach a screen shot demonstrating this as well. It can be corrected by resizing the window (inducing a re-paint).

This is a screenshot of the test case after typing "The quick brown fox jumps over the lazy dog". Note the cursor position and graphics corruption at the end.

This is with the entire line selected.

This is with the initial capital 'T' deselected. If you compare this closely to the screen shot where the entire line is selected you can see the character spacing discrepancies and some graphics corruption on the last 'g'. I find a good way to make the comparison is to drag both images to the drawer of a single open Preview.app window, and alternate between them by selecting each file back and forth in succession.

This is after backspacing a few times over the sentence.

(In reply to comment #11) > One live example is http://souceforge.net, Oops, should have read, "One live example is http://sourceforge.net, ..."

I experienced the same behavior as #13 with Firefox 1.0.3 on Mac OS X 10.4

https://bugzilla.mozilla.org/show_bug.cgi?id=288047 has apparently identified the problem, and posts a workaround.

It's not clear to me this is related to bug 288047. As I post there, that bug (at least for me) seems to depend on whether the encoding is UTF-8 or not. I have this bug in pretty much all locales (although admittedly less when the locale is iso-8859-1