202834 - click / cursor problems in mail compose / editor (works better on reply, than with new messages) / textareas

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[(not reading, please use [e-mail] instead)]

click / cursor problems in mail compose / editor (works better on reply, than
with new messages)

if I compose a new message, with this for the body:

this is a body test, more to follow
this is a body test, more to follow
this is a body test, more to follow
this is a body test, more to follow
this is a body test, more to follow

so now imagine your compose window / editor new page as four quadrants.

lines of text(1)  blank(2)
blank(3)          blank(4)

clicking in blank(4) doesn't seem to do the right thing:  move the cursor to the
end of the document.

clicking in (2) and (3) seem to work ok.

note, doing this in a quoted reply seems to work much better, except that double
clicking in blank(2) (when this is a reply) opens up the "advanced property
edit" dialog for the block quote element.  that sounds like an editor feature
that has made it's way into html mail compose (on accident?)

Comment 1

[(not reading, please use [e-mail] instead)]

> except that double clicking in blank(2) (when this is a reply) opens up the 
> "advanced property edit" dialog for the block quote element.  that sounds like 
> an editor feature that has made it's way into html mail compose (on accident?)

I get a similar dialog, when double clicking beyond a line that is a link (I get
the link properties dialog).

I'll spin this issue to another bug.

Comment 2

[kinmoz]

--> mjudge

Seth is this a regression? If so I'm wondering if it's a dup of bug 202677.

Comment 3

[(not reading, please use [e-mail] instead)]

brendan seems to think it is a recent regression, so this might be a dup.

Comment 4

[Scott MacGregor]

I believe this is a recent regresion. I believe I started seeing it in
Thunderbird between Thursday and this weekend (my two cents from the peanut
gallery). Those dates seem to match up well with when Bug #202677 was filed. 

Comment 5

[saari (gone)]

I believe this is a dupe of bug 202677, but that's a nice description of the problem

Comment 6

[mjudge]

Attachment: patch for nsLineBox in layout\html\base\src

fixes the regression.  the regression was caused from the bug to prevent caret
jumping on lines with 0 width frames.  This fixes the logic involved in finding
the proper frame on the line without going beyond the lines boundaries.

Comment 7

[mjudge]

*** Bug 202677 has been marked as a duplicate of this bug. ***

Comment 8

[Jason Bassford]

Comments from bug 202677:

This is also happening with texareas - such as when entering Bugzilla comments
as I'm doing now.  When clicking on whitespace to the right of the last line of
text in a paragraph (prior to a carriage return), the cursor is moved to the end
of the line of text *below* the line of text you'd actually clicked to the right
of.  If there *is* no line of text below the last line in the paragraph you'd
clicked to the right of, then nothing happens.

It's not just the mouse cursor/pointer that's behaving oddly, it's also the
cursor keys.  Consider the following four lines of text (you can copy/paste them
into the "Additional Comments:" box as a test):

aaaaaa
bbb
cccccc
ddd
eeeeee

If I have the cursor after the last "c" and hit the up arrow, the cursor moves
to the right of the 1st "c" rather than actually moving up a line. Additionally,
if my cursor is to the *left* of the last "e" and I hit up arrow, the insertion
point is moved to the left of the last "c", *not* to right of the last "d" as it
is when I have the insertion point positioned to the right of the last "e".  In
reverse, if the insertion point is anywhere to the right of the 3rd "a" and I
hit down arrow, rather than going down to the right of the last "b" I'm taken to
the right of the 1st "c".

-> All/All.

Product / Summary should also be changed to Browser / Selection.  (Or at least
to something other than MailNews/Composition specific.)

Comment 9

[Jesus Cea]

I experiment same problem reported in comment #8.

Build 2003042112.

Comment 10

[kinmoz]

Comment on attachment 121300 [details] [diff] [review]
patch for nsLineBox in layout\html\base\src

sr=[e-mail]

Comment 11

[mjudge]

checked in

Comment 12

[Jason Bassford]

Confirming that all textarea mouse/cursor key problems are now fixed (what a
relief).  I can't mark this Verified, however, since I don't use Mail/News and
can't confirm that aspect of the bug.

Comment 13

[lohphat]

I would say yes, confirmed fixed, but...

One would expect that if you mouse clicked below the end of a new mail's sig
text that the cursor would position to the end of the last line of the sig.

It positions in the line vertically above the mouse click.

I assume that might be cosnidered a new bug?

Comment 14

[Kathleen :Brade]

[e-mail] (comment 13)--I'm guessing you are on Windows?  That is
expected behavior on Windows (I believe most (not all) editors on Windows behave
like this).  On Mac (and maybe linux?) there is a pref to get the behavior you
desire.

Conclusion--if you are on windows, it is not a regression--it is intended
behavior; else please file a bug.

Comment 15

[lohphat]

Yes, Winderz.

Filing a bug with Redmond now...

Comment 16

[sairuh (rarely reading bugmail)]

even though the problem i had seen in bug 202677 is now fixed, i think the fix
here caused bug 195080 to regress.

Comment 17

[esther]

Using trunk builds 20030424 on linux and 20030423 on winxp and macosx this bug
as originally reported is fixed.  Verified, Note: bug 195080 is opened and a
possible regression due to the fix of this bug. 

Comment 18

[Axxackall]

The bug is back (regression again?) on 1.6 and 1.7b (both macosx).
BTW, it's as bad on replies as on new messages for me.