209714 - Weird caret and spacing behaviour when removing header line of quoted mail text.

Status: NEW

(Core :: DOM: Editor, defect, P3)

Description

[Kai Engert (:KaiE:)]

I'm filing this bug on behalf of Brendan, who reported the problem.
I'm not sure if this bug is editor:core or selection.
This bug is not seen in Mozilla 1.3, but 1.4 and later have the bug.

To reproduce
- compose a new mail message
- type some words
- send mail to yourself
- receive the mail message
- hit reply

You should now see the original message contents prefixed with a line like:
  Darth Vader wrote:

- place caret at the top of the message
- delete the full first line, for example by: hit and hold shift, hit arrow
down, release shift, hit DEL

Expected behaviour (as seen with Mozilla 1.3):
  The first line should disappear completely.
  All lines below should move up by one line.
  The new first line should be shown directly at the top
  of the editing window.

Actual behaviour (as seen with Mozilla 1.4):
  The contents of the first line are removed,
  but the content below does not move up.
  An empty line is now shown at the top.
  The shown empty line behaves as a real line,
  because you can arrow out of it, and back into it.

This empty line seems to be an layout problem.
The empty line can be seen in mail editing only.
It is a bug that this empty line is shown, because in terms of editable content,
there is no line. This can be confirmed by trying to delete the empty line.
Instead of deleting only the empty line, the delete action will instead remove
the content that follows below!

For some yet unknown reason, this bug behaves slightly different, when editing a
similar document in non-mail mode. When saving the mail message to a file,
removing mail message lines, editing the resulting html file in editor, removing
the first line: The Caret still (incorrectly) appears above the other content.
It appears the line above the shown is much smaller than in mail mode. The caret
seems to be at an invalid position now, because once you arrow away from it, you
can not go to that position again.

Comment 1

[Joe Francis]

I don't see this bug, at least not quite the same way.  When I delete that line,
I am still left with a <br> ahead of the mailcite.  So the blank line really is
there, in terms of content.  Then if I hit forward delete again, it pulls the
first line out of the mailcite into the body.

So I see two issues:

1) It seems we are putting in a <br> when deleting that first line, even if the
original <br> was selected and deleted.  This is likely an effect of editor
efforts to not leave the caret in no-mans-land.  In general this is desired
behavior, so we have to be very careful about changing that here.

2) When we have the empty line ahead of the mailcite, and hit DEL, we should
detect that we have an empty line and delete it, placing selection inside
mailcite.  Instead we are pulling out the first mailcite line.  Pulling out the
first mailcite line is exactly the right thing to do if we hit DEL at the end of
a non-empty line, but users have different expectations for DEL on empty lines.

Comment 2

[Kai Engert (:KaiE:)]

Some more info from Joe from IRC:

"i think the first part of the behavior *may* be ok
otherwise users can get confused about how to type before the mailcite after
deleting the first line
but the second part (not being able to delete blank line) definitely needs fixing
There is an IsEmptyLine() call in the deletion code
a good first step is to see if that is getting called, and what it is returning"

Comment 3

[Brendan Eich [:brendan]]

If I delete the first line, I shouldn't see a break.  If I need to put the caret
at the upper left corner of the editing area, even though the mailcite was
pulled up to start there, I can do that -- then if I hit Enter, I should create
an empty first line.

In other words, I think (1) is a bug too.  What am I missing?

/be

Comment 4

[Joe Francis]

Brendan: You are not missing anything.  I'm just concerned that some users won't
realize that hitting return will accomplish that.  

Note to self: if we do this the way Brendan requests, we have to make sure that
selecting all and typing cuases text to appear above the cite, rather than in it.

Comment 5

[Brendan Eich [:brendan]]

Correct me if I'm wrong, but Mozilla used to work the way I want, up until
recently (1.3?  1.4?  I'm not sure).

/be

Comment 6

[Joe Francis]

That wouldn't surprise me.  But something else probably *didn't* work the way
you expected, until whatever checkin had this effect.  The deletion code was
largely rewritten - made more general, more correct (mostly), and easier to
maintain, somewhere around 1.2 or so.  It may be that landing that caused the
change.

Comment 7

[Kevin McCluskey (gone)]

editorbase+ for "not being able to delete blank line".

Comment 8

[Samir Gehani]

adt: nsbeta1-

Comment 9

[Makoto Kato [:m_kato]]

old bug.  down to P3

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)