Closed Bug 8315 Opened 26 years ago Closed 26 years ago

Can't type return in plain text mail compose window

Categories

(MailNews Core :: Composition, defect, P3)

All
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: scurtis, Assigned: mozeditor)

Details

I looked for a dupe, but couldn't find one.

Return character doesn't show up in plain text mail compose window. Tested on
Linux 6_15, 6_16 and Mac 6_16 builds.

It shows up in the mail upon receipt and display.

It works in html compose.
QA Contact: lchiang → scurtis
Assignee: ducarroz → buster
should be an Ender matter... reassign.
could the submitter be more specific?  The three interesting cases are:
1) what happens when you hit return at the very beginning of the document?
2) what happens when you hit return with your selection in the middle of some
text?
3) what happens when you hit return at the very end of the document?

Does return fail to display in all these cases?  Do you see vertical spacing
increase, but no caret?  Or does the vertical spacing stay the same?
1/ Hitting return at the beginning of the document drops the line by one.
Further returns do nothing.
2/ Hitting return in the middle of text adds one space. Further returns do
nothing.
3/ Hitting return at the end of a message adds one space. Further returns do
nothing.

These tests are in Messenger compose.
Assignee: buster → jfrancis
Target Milestone: M8
reassigned to Joe.  If this is a problem with the rules code, it should be fixed
asap.  Thanks.
Also occurs in Win32 build 1999062113.  A similar problem is that you can't
press space bar twice - the first time you press space bar, you get a space.
The second consecutive time you press it, nothing happens.  (if you want this as
a separate bug, let me know.)
Status: NEW → ASSIGNED
accepting bug
Assignee: jfrancis → buster
Status: ASSIGNED → NEW
Steve, I took a look at this.  What's going on here is that the selection is
getting outside the <pre> tag.  I got this to happen in two ways:

1) select all, delete (then there is no <pre> tag left)
2) click at end of text, then right arrow once

This is not a rules issue.  Maybe I shold still have this bug, but I nominate
Mike if he's available.  The real issue here is that our plaintext implementation
implies that _selection_ also needs to have some rules.

We need to get this on the schedule and assign someone to it.

assigning to buster for disposition, cc'ing mike
Assignee: buster → jfrancis
hmmm... i've thought some more about this, and decided that i should own this
bug.  although we need to do special things with selection, these things should
not be done BY selection (but rather TO selection) and should be handled in the
text editor rules.

I'll try to fix this.
Status: NEW → ASSIGNED
my earlier comments about how to get in this state were wrt to the plain text
editor, as opposed to plain text mail compose.  For mail compose I assume we are
also failing to set the initial selection to be inside of the pre tag.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Fixed, though in so doing I've created bug 9153
Status: RESOLVED → VERIFIED
Hm. Well, I suppose this is fixed, in some sense, because when I'm typing in a
plain text compose window, the returns appear to be inserted.

However, now I have the reverse problem: after sending the message and viewing
it, the returns are not there. (7_7 Linux)

I guess I'll open a separate bug on that. I have no idea from the phrasing of
9153 if it's related to that or not.

Marking this as verified fixed.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.