Closed Bug 377104 Opened 14 years ago Closed 13 years ago

Cursor does not hold position in a text box when scrolling and creates "ghost" cursors


(Camino Graveyard :: Page Layout, defect)

Not set


(Not tracked)



(Reporter: ewanog, Unassigned)




(Whiteboard: DUPEME, [CLOSEME - 6/13])


(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv: Gecko/20070406 Camino/1.1b+
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv: Gecko/20070406 Camino/1.1b+

With text boxes (only some), if I scroll up or down, the cursor follows and does not stay where it should be according to position with the text. If i scroll far enough it will even leave the text box, but when I start typing again it snaps back into place, but the "ghost" cursors still remain.

For example:

Text |  << Cursor

When I scroll down the following occurs

Text |


     | (This bottom is blinking because it is where I stopped scrolling)

However, when I scroll side to side the cursor only "hangs" and creates the ghost image if the side I'm scrolling to contains text.


*Scrolling left where there is text*

Te|(Blinking cursor)xt |

*Scrolling right where there is no text*

Text | (Blinking cursor)

Reproducible: Sometimes

Steps to Reproduce:
1.Go to the text box
2.Enter text 
3.Scroll up or down (or left and right depending if there is text)
Actual Results:  
The same thing I described earlier

Expected Results:  
The "ghost" cursor should not have appeared, there should have only been one cursor, and no duplicates.

I'm not positive, but I'm pretty sure that wordreference (the site with the problem) uses a JAVA text box. I have not had the same problem with other text boxes, just that one.

If I did not describe clearly enough I can post a screen shot.
I'm sure this is a dupe of one of the bugs fixed by the caret rewrite on the trunk....
Whiteboard: DUPEME
Ewan, can you reproduce this behaviour in a trunk nightly?

If not, then this is WORKSFORME unless someone wants to track down the specific bug.

If you *can* still reproduce this behaviour, please post a screen shot, because I'm not at all clear what, exactly, the problem is.

Whiteboard: DUPEME → DUPEME, CLOSEME 6/13
Attached image Screenshot of ghost cursor (obsolete) —
I'm also experiencing this issue with Camino 1.5 in Gmail.  Here is a screenshot.  Notice the ghost cursor in the upper left, down and to the left of the bold button.
I'm just going to close this WORKSFORME since we don't know a specific bug number and no one has said it's still broken on trunk. Henry or Ewan, feel free to try a 2.0pre nightly from

and reopen this bug if the issue persists.
Closed: 13 years ago
Resolution: --- → WORKSFORME
I can't reproduce ghost cursors in Gmail on the branch, FWIW (though once upon a time before 1.5 I was able to).
Whiteboard: DUPEME, CLOSEME 6/13 → DUPEME, [CLOSEME - 6/13]
I just tried this using Version 2007062522 (1.6a1pre) and I still get ghost cursors in gmail.
Henry, can you try one of the trunk builds from and see if you still get ghost cursors in Gmail with that?
I downloaded the build you pointed me to (Version 2007062722 (2.0a1pre)), but I cannot test to see if the issue is reproducible: Gmail won't display rich text editing mode for this build, and the ghost pointers only showed up in rich text mode to the best of my knowledge.
(In reply to comment #7)
> Henry, can you try one of the trunk builds from
> and see if
> you still get ghost cursors in Gmail with that?

Now that I can see the cursor in the rich text compose, I tested this again with Version 2007082102 (2.0a1pre).  The ghost cursors are still there, but seem to be limited to inside the compose box, and happen less frequently.  Attaching a picture of the issue.
Attachment #268964 - Attachment is obsolete: true
Henry, can you check the latest Minefield build to see if it has ghost cursors, too?

If so, the bug belongs in Core somewhere (and we maybe want to file a new, clean bug for it).
Yes, it does occur.  I will file a new bug and CC you on it.
New bug id: 393436
You need to log in before you can comment on or make changes to this bug.