309653 - When forwarding or replying to messages the new composition window opens with To: and Subject line greyed out, and inline text is missing.

Status: VERIFIED DUPLICATE of bug 307672

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Isaac]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a Mnenhy/0.7.2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a Mnenhy/0.7.2.0

Messages cannot be forwarded or replied to.  Nothing can be typed in the To,
Subject, or Body fields.  To clear this problem it is not enough to shut down
Mail.  The entire program must be shut down and restarted.  

Reproducible: Sometimes

Steps to Reproduce:
1. ?
2.
3.



Expected Results:  
In the composition window that pops up after hitting Forward or Reply:

Include original sender/allow other recipients to be added to the To: field.  
Include original text in the Body.

Comment 1

[OstGote!]

Do you see any errors in the JS console?

Comment 2

[Alexander Kluss]

I have the same with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050904 SeaMonkey/1.1a

I get two entries in the JS Console the first when I open the reply or compose
window

Error: [Exception... "Component returned failure code: 0x80004003
(NS_ERROR_INVALID_POINTER) [nsIMsgCompose.initEditor]"  nsresult:
"0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame ::
chrome://messenger/content/messengercompose/MsgComposeCommands.js ::
InitEditor :: line 3187"  data: no]
Source File:
chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 3187

and the second when I close the reply or compose window.

Error: gMsgCompose.editor has no properties
Source File:
chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 189

When I close the window and I quite the question if I want to save the changes
in the window with "yes" there would not be save the message.

I could not safe reproduce the bug but it could be the first reply in the
session or after 10 or 20 messages. It's equal if I use the browser or not in
the background.

Comment 3

[Isaac]

(In reply to comment #1)
> Do you see any errors in the JS console?

Embarrassed to say I don't use JS console.   If you can use more information
than Alexander's response, point me what to do and I'll do my best.   Thanks. 

Comment 4

[mg8]

I found this behavior with Seamonkey 1.0a (09152005; the 1.0a version that can
be downloaded from the Seamonkey page) frequently with Win98. The very first
email worked, but after that I couldn't send any emails anymore.
(For now, I stepped back to Mozilla 1.7.11 ...)

Comment 5

[Johannes Kastl]

(In reply to comment #4)
> I found this behavior with Seamonkey 1.0a (09152005; the 1.0a version that can
> be downloaded from the Seamonkey page) frequently with Win98. The very first
> email worked, but after that I couldn't send any emails anymore.
> (For now, I stepped back to Mozilla 1.7.11 ...)

The same for me on WindowsXP. Quite annoying.

Comment 6

[Andrew Schultz]

Isaac: JS Console can be accessed via Tools->Web Development->Javascript Console

Comment 7

[Onkar Shinde]

Not reproducible on Windows 2K SP4, SeaMonkey 1.0alpha.

Comment 8

[Isaac]

(In reply to comment #7)
> Not reproducible on Windows 2K SP4, SeaMonkey 1.0alpha.
> 

For the record, I am using SP4.

Comment 9

[Johannes Kastl]

I am experiencing this bug now in XP SP2 with
SeaMonkey 1.0b
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8) Gecko/20051210 SeaMonkey/1.0b Mnenhy/0.7.3.0

Not reproducible. Nasty.

Comment 10

[Lewis Rosenthal]

I see this (the symptom; I haven't yet had an opportunity to check with JS console) with the 2005-12-20 nightly trunk (SeaMonkey 1.5a) on OS/2. In my case, shutting down SeaMonkey does not help, and the problem (so far) has been consistent/persistent. I first thought that Mnenhy was at fault, but after uninstalling it, the problem persists. The issue does not appear to be in my profile, as rolling back to the 2005-12-05 nightly works just fine (my previous nightly in use was 12-14, and I did not see this issue with that build).

Anyway, I'll do some more QA with this later today, and post my JS console data. If I am seeing this issue on trunk, then perhaps the bug should be changed to reflect that (right now, this one is targeted at the 1.8 branch).

BTW, I could not select an identity to use, either; the list was empty.

Lewis

Comment 11

[Bruno 'Aqualon' Escherl]

Attachment: error in SeaMonkey console and JS console

Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b

The black part at the bottom of the attachment is the message I get in the SeaMonkey console.

Still no clue how to reproduce this.

Comment 12

[David :Bienvenu]

can you try a build from 12/20 or later? I checked in a change to nsMsgCompose.cpp on 12/19 that may fix this.

Comment 13

[Lewis Rosenthal]

(In reply to comment #12)
> can you try a build from 12/20 or later? I checked in a change to
> nsMsgCompose.cpp on 12/19 that may fix this.
> 
David, it may have been your patch which causes the symptom I mentioned in comment #10. I make this statement solely based on the date of my experience vs the date you checked in the code.

I tried the 12/23 nightly and now, the 12/28 build, and have the same issue per my earlier comment. Note that contrary to the bug description, what I have is an empty list of identities and no signature when composing new or replying, and when replying, no addressee (though I can, in fact, enter an addressee in the To: field), no subject, and no quoted text. Different bug? Related to your patch? What can I do to help track it down?

I said that I would do some QA with it when I posted my last comment, and got bogged down with other stuff. I'll try to get back to it tonight, but some guidance would be appreciated.

As I mentioned in comment #10, I'm seeing this on trunk, and haven't yet tested the 1.8 branch.

Thanks!

Lewis

PS - for reference: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051228 MultiZilla/1.8.1.0u SeaMonkey/1.5a

Comment 14

[David :Bienvenu]

Lewis, did you post your js console info, if any?

Comment 15

[Lewis Rosenthal]

(In reply to comment #14)
> Lewis, did you post your js console info, if any?
> 
No, David, I have not. However, I can confirm that my issue is indeed different from this bug, as I have just installed (using now) 12/28's 1.0b from the 1.8 branch, and it works fine (reply and new composition).

I'll double check that there is not yet a bug entered for what I'm seeing on trunk, I'll create a new profile, and test again. I may indeed have some extension which is incompatible with the newer nightlies; you never know.

Lewis

PS - If you still think there's a need for my js console info, please advise and I'll post it.

Comment 16

[David :Bienvenu]

If this was introduced in the 12/20 build, a js console log might be interesting, especially if it was my checkin that caused it, and not some extension incompatibility.

Comment 17

[Lewis Rosenthal]

(In reply to comment #16)
> If this was introduced in the 12/20 build, a js console log might be
> interesting, especially if it was my checkin that caused it, and not some
> extension incompatibility.
> 
No, David, this issue (for me, at least) was something related to my installation directory, and probably a leftover (or copied over) file from a previous build which post-12/18 builds didn't like. A *clean* install of the 12/28 trunk build works like a charm, extensions and all.

My apologies for wasting your time this evening. I should have followed through with my original statement to inspect the situation further. I can now state that I do not see this issue on either the 1.9 trunk or the 1.8 branch with the latest nightlies (on OS/2). I can't speak, of course, for Isaac, who was the original reporter of this bug.

Lewis

Comment 18

[Wolfgang Rosenauer [:wolfiR]]

*** This bug has been marked as a duplicate of 307672 ***