21683 - [dogfood] Can't set focus to end of reply message to type

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[Jim Roskind]

With the lack of arrow keys, I'm now completely unable to direct focus to where
I intend. (maybe arrow keys wouldn't help... but I'm really at a loss as
present)  This is especially notable when dealing with the indented content in a
reply.

Example:

a) Select a message
b) press reply (in HTML edit mode)
c) Set focus on the end of the indented message
d) press delete a few times to delete *all* following characters.
e) Using the mouse, try to set the focus to the end of the indented message
f) Try to type

Rather than having your typing appear at the end of the indented message, it
appears at the start of the entire message, many lines away.  There seems to be
no way to get focus to the end of the message to type.

The way this happens in "real life" is that you hit reply, and then delete the
last 9/10ths of the original message.  Then you try to put down your reply...
and you can't :-(.

Worse yet, it looks really unstable to be typing at the end of the message, and
have text appear at the start of the message!!

IMO, there have been a series of regressions surrounding the start and end of a
message text region.  I suspect (based on work I did years ago) that this is all
related to setting the cursor, and edge effects in an editable region. ...but
I'm just guessing.  We need to be sure we can insert text at the start of a
message, and append text to the end of a message, and get focus at these points
and everywhere in between.

Thanks,


Jim

Comment 1

[rubydoo123]

assigning to saari, this problem came about after the checkin on Friday.

Comment 2

[leger]

Putting on PDT+ radar.

Comment 3

[saari (gone)]

What checkin on Friday?

Comment 4

[saari (gone)]

I don't see how this can be my problem, moreover, for dogfood, try the return
key.

I really don't think this is related to my focus work at all, this is inside of
the ender widget.

Comment 5

[Jim Roskind]

Sarri: please don't misunderstand: I just see the bug, and have no idea where it
came from.

With regard to the "try the return key": It does nothing. The cursor remains on
the last character no matter how many times you hit it. When you then type text,
it appears at the start of the message.  The best you can do is split the
remnant of the message by setting focus into the middle of a word, and then
typing... but it immediately does an implicit return, breaking the word with
your typing, and splitting the indented region.

This is a confusing pain... and I couldn't figure out a way to "Repair" the
message and get my text added in.  In the end, I gave up, and went back to 4.x
:-(.   Maybe you'll find a way... though it was not obvious to me.

Comment 6

[rubydoo123]

assigning to Kin then so he can take a look and debug the issue

Comment 7

[kinmoz]

Accepting bug. This may be an editor rules problem so I'm also Cc'ing
[e-mail].

Comment 8

[chris hofmann]

kin,  how is this investigation going?  thanks -chofmann

Comment 9

[kinmoz]

I can't reproduce the bug where the caret jumps to the start of the message.
Maybe Jar can demo it for me, or send me the document he is replying to.

Jar, are you expecting to be able to add text into the quoted region without
breaking it up? If so, the editor rules code doesn't allow that right now. It
automatically splits the quoted text into 2 blocks and inserts what you type
between it, just as you mentioned above.

I did notice a bug in the editor rules code that prevents us from hitting the
return key and inserting a blank line when at the very end of the quoted text,
but you can add text after the quoted text by simply placing the caret at the
very end of the quoted text and just typing.

Comment 10

[kinmoz]

Here's a fix for the problem where the return key does nothing when the caret is
at the very end of the quoted text section. I can't check this in until
[e-mail] looks at it and says that I put the fix in the correct
place in the rules code.

Index: nsHTMLEditRules.cpp
===================================================================
RCS file:
/cvsroot/mozilla/editor/base/nsHTMLEditRules.cpp,v
retrieving revision 1.80
diff
-c -r1.80 nsHTMLEditRules.cpp
*** nsHTMLEditRules.cpp	1999/12/07 08:28:41	1.80
--- nsHTMLEditRules.cpp	1999/12/15 20:53:54
***************
*** 490,495 ****
---
490,497 ----

      if (citeNode)
      {
+       nsAutoRules
beginRulesSniffing(mEditor, nsHTMLEditor::kOpInsertBreak, nsIEditor::eNext);
+

       res = mEditor->SplitNodeDeep(citeNode, selNode, selOffset, &newOffset);

      if (NS_FAILED(res)) return res;
        res =
citeNode->GetParentNode(getter_AddRefs(selNode));

Comment 11

[Joe Francis]

Kin's fix is the right idea, but I think the place to put in the nsAutoRules var
is up in nsHTMLEditor::InsertBreak().  Kin, can you give that a try?  Or if you
want you can asign to me and I'll test the fix.

Comment 12

[kinmoz]

I moved the fix into nsHTMLEditor::InsertBreak() and it still works. :)

I'll check this in as soon as I get permission.

Comment 13

[kinmoz]

Checked in fix:

    mozilla/editor/base/nsHTMLEditor.cpp  revision 1.201

r=[e-mail]  a=[e-mail]

Fix should appear in the 12/16/99 builds.

Comment 14

[laurel]

Looks OK to me using 12-16-12m12 commercial builds on linux 6.0, NT 4.0 and Mac
OS 8.5.1.

I did hit an instance where I jump to the top of the message instead of breaking
and being able to type below quoted message, but I think it would be a separate
issue:  I encountered a message where the html quoting included several blank
lines at the end of the text of the message, i.e. there was a blue line
indicating quoting which reached past the message text by 6 or 7 lines. If I
tried to mouse click on a quoted blank (no text) line at the bottom of the
quoting area, I could not break or delete or anything and when I typed, the
focus was still at the top of the message body so that's where my added text was
placed.   This was not the norm in reply quoting and all other instances seemed
to be fine.  So am marking this verified, will investigate the blank line
quoting at end of message as separate possible bug.