8554 - Regression - can't type in msg body of plain text compose window

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[pmock]

Build:
  PPC June 19 Seamonkey build (1999-06-19-08-M7) running on PPC 9600/300 OS 8.51

Problem:
  Regression.  In todays build, you can not type in the message body of Plain
Text compose window.  There is no caret/cursor that appears when you
click/double click into the body.  I see this problem in a single POP profile as
well in a multi-user profile.

*This problem does not occur in the Rich Text HTML compose window.

If you type in a address and subject, you can still send the message. The
message that is received displays the full header information in the message
body.

This bug is different from bug 8481 where you have to place cursor before you
can type.

Note: Scurtis and Suresh have already passed the today Win32 and Linux build so
this is a parity bug.  This is a regression because in the previous Mac builds,
you could type in the message body.  I went back and tried yesterday Mac build
(1999061808) and could type in the message body of a plain text compose window.

As a test, I was able to reproduce problem on another PowerPC.  It was a PPC
2300c Duo running Mac OS 8.5.1.  The problem occurs on this machine too.  I was
running a single pop profile on this machine

Steps to reproduce problem:
0) Edit your prefs50.js and add the line
     user_pref("mail.identity.id1.send_html", false);
   It does not matter if you have a single or multi-user profile
1) Start Apprunner
2) From the Task menu, select Messenger
   Wait for the Messenger window to appear
3) Click on the New Msg button
   Wait for the Plain Text compose window to appear
4) Type in a email address and a subject
   You must manually start by placing your caret/cursor on the To: line
5) Click in the message body of the Plain Text compose window
   Notice that a I-bar does not appear
6) Double clicking into the msg body area and try to type
   No I-bar again and no text is entered
6) Select the sample text "--This message was sent by Messenger 5.0"
7) Try to type
   Nothing happens - No I-bar and no text
8) Try using the arrow keys and try to type
   No I-bar appear and no text

Comment 1

[pmock]

Correction... after testing on Linux (1999061908) and Win32 (1999061908), this

problem occurs on all platforms.  Thanks Suresh for your help. :)



Changing plaform from Mac to "All"

Comment 2

[scottputterman]

On Windows I get the following debug assertion stack when I try to type

NTDLL! 77f76148()
nsDebug::PreCondition(const char * 0x01b328c0
??_C@_0DJ@KMGL@You?5can?8t?5dereference?5a?5NULL?5nsC@, const char * 0x01b32904
??_C@_0N@NHHF@mRawPtr?5?$CB?$DN?50?$AA@, const char * 0x01b34e90
??_C@_0CB@MCGB@?4?4?2?4?4?2?4?4?2dist?2include?2nsCOMPtr?4h@, int 477) line 126
+ 13 bytes
nsCOMPtr<nsIContent>::operator->() line 477 + 34 bytes
nsRangeList::GetPrimaryFrameForFocusNode(nsRangeList * const 0x04b3fe60,
nsIFrame * * 0x0012f940) line 1089 + 12 bytes
nsRangeList::HandleKeyEvent(nsRangeList * const 0x04b3fe60, nsGUIEvent *
0x0012fbb0) line 1028 + 16 bytes
PresShell::HandleEvent(PresShell * const 0x04b3ff34, nsIView * 0x04b45a10,
nsGUIEvent * 0x0012fbb0, nsEventStatus & nsEventStatus_eIgnore) line 2018
nsView::HandleEvent(nsView * const 0x04b45a10, nsGUIEvent * 0x0012fbb0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 833
nsView::HandleEvent(nsView * const 0x04b42a40, nsGUIEvent * 0x0012fbb0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x04b42ad0, nsGUIEvent * 0x0012fbb0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsView::HandleEvent(nsView * const 0x04b3d2d0, nsGUIEvent * 0x0012fbb0, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 818
nsViewManager::DispatchEvent(nsViewManager * const 0x04b3d4f0, nsGUIEvent *
0x0012fbb0, nsEventStatus & nsEventStatus_eIgnore) line 1735
HandleEvent(nsGUIEvent * 0x0012fbb0) line 67
nsWindow::DispatchEvent(nsWindow * const 0x04b46434, nsGUIEvent * 0x0012fbb0,
nsEventStatus & nsEventStatus_eIgnore) line 408 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fbb0) line 429
nsWindow::DispatchKeyEvent(unsigned int 133, unsigned short 0, unsigned int 72)
line 1823 + 15 bytes
nsWindow::OnKeyDown(unsigned int 72, unsigned int 35) line 2016
nsWindow::ProcessMessage(unsigned int 256, unsigned int 72, long 2293761, long *
0x0012fda8) line 2341 + 40 bytes
nsWindow::WindowProc(HWND__ * 0x00080728, unsigned int 256, unsigned int 72,
long 2293761) line 471 + 27 bytes
USER32! 77e71250()

The reason is that after these lines in GetPrimaryFrameForFocusNode

  nsCOMPtr<nsIContent> content = do_QueryInterface(node);
  PRBool canContainChildren = PR_FALSE;
  nsresult result = content->CanContainChildren(canContainChildren);

content is null

Comment 3

[Simon Fraser [no longer active]]

putterman's crash and stack is a different problem, and one which just got
fixed: http://bugzilla.mozilla.org/show_bug.cgi?id=8557.

Comment 4

[Simon Fraser [no longer active]]

This was a typo in the plain text editor factory; it broke the plain text editor
too. I checked in a fix, seth reviewed.

Comment 5

[leger]

Peter is this fixed with Jun 20 build?

Comment 6

[leger]

Actually...doesn't look like Jun20 M7 is out yet...only M8...soon...:-)

Comment 7

[leger]

If this is fixed on all platforms, we could have a go on M7..how we lookin? :-)

Comment 8

[pmock]

Verified in the June 21 Seamonkey builds.  I tested the following builds under
IMAP and POP.  They are:
  PPC June 21 Seamonkey build (1999062114) installed on PPC 8600 OS 8.5.1
  Linux June 21 Seamonkey build (1999062115) installed on Compaq P200 RedHat 5.2
  Win32 June 21 Seamonkey build (1999062113) installed on Gateway P200 Win98

In these builds, I was able to type into the message body.  Bug 8481 appears
better. I don't have to double click in the message body.  A single click into
the message body and I can type text.

However, bug 8315 still exists.  Carridge returns don't show up in plain text but
are sent.
HTML is ok

Verified as fixed