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

VERIFIED FIXED

Status

MailNews Core
Composition
VERIFIED FIXED
15 years ago
6 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: mjudge)

Tracking

({regression, topembed})

Trunk
regression, topembed

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: editorbase)

Attachments

(1 attachment)

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?)
> 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

15 years ago
--> mjudge

Seth is this a regression? If so I'm wondering if it's a dup of bug 202677.
Assignee: kin → mjudge
brendan seems to think it is a recent regression, so this might be a dup.

Comment 4

15 years ago
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. 
Keywords: nsbeta1, regression

Comment 5

15 years ago
I believe this is a dupe of bug 202677, but that's a nice description of the problem
(Assignee)

Comment 6

15 years ago
Created attachment 121300 [details] [diff] [review]
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.
(Assignee)

Comment 7

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

Comment 8

15 years ago
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.)
OS: Windows 2000 → All
Hardware: PC → All
Summary: click / cursor problems in mail compose / editor (works better on reply, than with new messages) → click / cursor problems in mail compose / editor (works better on reply, than with new messages) / textareas

Updated

15 years ago
Keywords: topembed
Whiteboard: editorbase

Comment 9

15 years ago
I experiment same problem reported in comment #8.

Build 2003042112.

Comment 10

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

sr=kin@netscape.com
Attachment #121300 - Flags: superreview+

Updated

15 years ago
Attachment #121300 - Flags: review+
(Assignee)

Comment 11

15 years ago
checked in
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 12

15 years ago
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

15 years ago
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

15 years ago
lohphat@earthlink.net (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

15 years ago
Yes, Winderz.

Filing a bug with Redmond now...
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

15 years ago
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. 
Status: RESOLVED → VERIFIED

Updated

15 years ago
Blocks: 204128

Comment 18

14 years ago
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.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.