72780 - Mozilla jumps caret randomly at end of text.

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[dylang]

In an edit box, such as the description box used to enter this bug info, Mozilla
will randomly move the cursor around in the body text if you click past the end
of the last bit of text.

For example, on http://www.kuro5hin.org, I tried to middle-click past a URL onto
the end of an <a href=" I had started at the end of the text box.  I didn't get
the middle click /exactly/ next to the last char, thus leading the past to go
and plop down halfway up the paragraph -- very annoying.

Perhaps a change in the cursor positioning logic to not "jump" the cursor if the
logical position indicated by the click is past the logical end of text would be
appropriate.

This bug exists in build 2001031611

Comment 1

[Asa Dotzler [:asa]]

updating component

Comment 2

[rubydoo123]

asking QA to test this on linux, I am not able to reproduce this on win98 using 
the build from 2001032904

Comment 3

[sujay]

Ican't reproduce this.

Dylan please provide step by step details.

Comment 4

[Kathleen :Brade]

I can't reproduce this on Macintosh either.  Is this only a problem for middle-
mouse pasting?

Comment 5

[rubydoo123]

Dylan, we are having trouble reproducing this one, I will mark this worksforme, 
but if you encounter this again, reopen and let us know the platform, the build 
and any other information that we could use to repro this.

Comment 6

[dylang]

I can reproduce very easily..

In X11 Mozilla, go to any text box.  Appened something like <a href=" (as we are
about to paste a URL!).. middle-click a few spaces to the right of the last
line, and watch the text blap into the box a few lines up (randomly).

It's definitely X11 specific.  If you can go try it on a local UNIX box, you'll
see what I mean.

Comment 7

[sujay]

verified in 3/29 build.

Comment 8

[Akkana Peck]

Dylan, this sounds like it might be getting the wrong coordinate for your mouse
click.  What version of XFree86 and gtk are you running (on what flavor of
Linux)? What kind of mouse do you have, and is there any possibility that your
mouse driver is nonstandard?  What else is in the text field before you type the
<a href= (you didn't mention that part in your repro instructions; if I only
type what you say to type, the caret can't jump a few lines earlier because I'm
already at the beginning of the textarea).  What page are you using to test
this, e.g. can I use the "Additional Comments" field in this bug report?

BTW, I haven't tried with a current build (just got back from being out of town
and my build is a bit over a week old) but I'll try it when there's a good linux
build to test (today's build had some blockers) or when my debug build is ready.

Comment 9

[dylang]

Slackware Linux  7.1
gtkglib:  gtk+-1.2.8, glib-1.2.8
XFree86 4.0.2
    Identifier  "Mouse1"
    Driver  "mouse"
    Option "Protocol"    "IMPS/2"
(Logitech wheely mouse dealy which works great)

The text field must be full enough that the right-hand up/down scroll bar is
active (ie: there is at least n lines, where n is greater than the number of
lines the box is specified to take vertically).  This "Additional Comments" box
exhibits the behaviour if you fulfill this requirement, for example.

Any text will also end up activating the misbheaviour.  The '<a href="' crunk is
merely a specific example.  If I type "assdfsdfsg" on the end line of a scrolled
box, and then go to past anything past the logical end of its line (and the end
of the entire text block), the output will appear a few lines up.  I've verified
that this happens in this "Additional Comments" box as well (as I write this
bugreport, in fact).

Since the behaviour only happens if the box is scrolled, I'm curious as to what
code path is being followed here.

Comment 10

[dylang]

Woo, additional information...

If you click beyond the logical EOL anywhere in a scrolled GTK edit box, the
cursor jumps randomly.  Just click, no need to middle click.  The edit box
should have a decent amount of text in it (I was editing an article on K5 of
some odd thousand words).

This cursor jumping is really annoying :/

Comment 11

[dylang]

Still happens in 2002020421.

Trivial to reproduce -- could we modify the code which reads in the values form
GTK+ or whatever to assume a gibberish value means the end of the text coords? 
It'd save grief.

Comment 12

[John Levon]

A fix mentioned in bug 106855 sounds vaguely similar, and landed after the
last comment here. So can anyone still reproduce it ?

Comment 13

[rubydoo123]

handing this over to Kin

Comment 14

[Vadim Berezniker]

Dylan, can you still reproduce this in a nightly?

If so, could you try upgrading gtk+ to 1.2.10 to rule out the possibility of a
gtk bug?

Comment 15

[dylang]

Well, this seems to be fixed in 2002032921.

I've always had GTK+ 1.2.10 (comes with Slack 8).

I'll reopen if I can reproduce :)

Comment 16

[sujay]

verified per comments.