303642 - Drag-n-drop caret is not drawn correctly on some empty lines

Status: RESOLVED DUPLICATE of bug 240416

(Core :: DOM: Selection, defect)

Description

[Mats Palmgren (inactive)]

Drag-n-drop caret is not drawn correctly on some empty lines.

STEPS TO REPRODUCE
1. load the attached testcase
2. drag text over the textarea and watch the caret

ACTUAL RESULTS
The caret does not appear anywhere when the mouse is on line 4.
The caret is drawn on line 5 when mouse is on line 6.

PLATFORMS & BUILDS TESTED
Bug occurs in SeaMonkey nightly build 2005-08-05-05 (gtk1) Linux
Bug occurs in SeaMonkey nightly build 2005-08-04-01 (gtk2) Linux

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 2

[Uri Bernstein]

This is likely due to 
http://lxr.mozilla.org/mozilla/source/layout/base/nsCaret.cpp#414 :
// XXX we need to do more work here to get the correct hint.

This is (somewhat) related to bug 303399, which I'm working on (also has to do
with wrong positioning of the caret on blank lines, due to a bad hint).

Comment 3

[Uri Bernstein]

Attachment: patch

This looks stupid, but it actually works. Tested both on empty and non-empty
lines, and both at ends and beginnings of lines. Everything works fine.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 192190 [details] [diff] [review]
patch

When trying to figure out why this worked, I found that the two empty lines
each have their own content offset, making me wonder why the hint is at all
necessary in this case. r=me

Comment 5

[Uri Bernstein]

Bah. After thinking about this for a while (something I should have probably
done before posting the patch), I found out the case which this does break: When
dragging over the end of an overflowing line. With this patch, the caret appears
at the beginning of the next line.

I still think this is an improvement over the previous behaviour (I'd think
dragging over blank lines is more common than dragging over edges of overflowing
lines, and also the placement of the caret on the next line is not completely
wrong, unlike the original bug). But I'm not sure.

mrbkap - do you want to re-consider your r+?

Comment 6

[Uri Bernstein]

And yeah, sorry about that.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #5)
> Bah. After thinking about this for a while (something I should have probably
> done before posting the patch), I found out the case which this does break:
> When dragging over the end of an overflowing line. With this patch, the caret
> appears at the beginning of the next line.

You mean a line that's wrapping, right?

I think I'd prefer to see this fixed for real. The editor listener that calls
DrawAtPosition should really be calling DrawAtPositionWithHint (then we can
remove DrawAtPosition). I think nsIDOMNSUIEvent should actually get a new method
that returns the hint (defined in a precise and sane way!). Then nsDOMUIEvent
can actually compute the hint in a way that ensures the caret will at least stay
on the right line. Basically if the content at the offset is on the desired
line, then "hint next", otherwise "hint previous".

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That new method would be a readonly attribute, say
  readonly attribute boolean rangeAssociateNext;

Comment 9

[Uri Bernstein]

(In reply to comment #7)
> You mean a line that's wrapping, right?
Right.

> I think I'd prefer to see this fixed for real.
I think I agree, but I'm not sure I'll be working on this. So reassigning back
to default owner (I'll also depricate the patch).

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Duplicate of bug 240416?

Comment 11

[Uri Bernstein]

(In reply to comment #10)
> Duplicate of bug 240416?

Certainly.

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