Closed
Bug 10139
Opened 26 years ago
Closed 25 years ago
Compose: if error sending, window doesn't close or display error
Categories
(SeaMonkey :: MailNews: Message Display, defect, P3)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
VERIFIED
FIXED
M11
People
(Reporter: jay, Assigned: bugzilla)
References
Details
(Whiteboard: [PR1])
compose message window does not close upon sending message
Steps:
1. Launch messenger
2. Click "New Message"
3. Compose a new message and click "Send"
Expected Behavior: Compose window should close upon sending message.
Actual Behavior: Window does not close, must be closed manually (message is
sent out ok)
Machine & Build: Win98 build 1999071911
Jay - I don't have this problem on today's Win32 builds. Isn't this the same as
that bug you reopened last week
http://bugzilla.mozilla.org/show_bug.cgi?id=4561k which was marked fixed?
Reporter | ||
Comment 2•26 years ago
|
||
No, this is different than 4561 because the message is actually sent ok. The
only problem here is that the window does not go away.
Updated•26 years ago
|
Assignee: phil → ducarroz
Comment 3•26 years ago
|
||
Hmm. I can't reproduce this either. When you get today's build, can you try
this out again and see if it's still happening. Reassigning to ducarroz and
cc'ing rhp.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•26 years ago
|
||
What could append here is that the message is correctly sent but the move to the sent folder failed. Therefore the
windows won't go away (same with 4.5). The real problem here is that we still not have alert to tell the user what
append!
Jay, could you give us the output you have in the dos window when the problem append.
Reporter | ||
Comment 5•26 years ago
|
||
I am still getting this with win32 build 1999072010...here is what DOS puts out:
Compose: ComposeStartup
[format=0]
[type=0]
Created nsEditorShell
Created editorShell
editor initialized in HTML mode
Attaching to WebShellWindow[]
Reading file...
Reading file...Done
SendMessage from XUL
GenericSendMessage from XUL
Looking for identity id1
Identity = [xpconnect wrapped nsIMsgIdentity]
Looking for identity id1
Alert: [StringID -2147024809?]SendMessage from XUL
GenericSendMessage from XUL
Looking for identity id1
Identity = [xpconnect wrapped nsIMsgIdentity]
Looking for identity id1
Alert: [StringID -2147024809?]
Assignee | ||
Comment 6•26 years ago
|
||
You get an error during the send:
Alert: [StringID -2147024809?]
Normally we should have displayed a nice alert box that would have explained the poblem!
Reporter | ||
Comment 7•26 years ago
|
||
If there is an error on the send, then why would the message be sent still. I
can send the message and receive it ok...it is read just as i wrote it.
Assignee | ||
Comment 8•26 years ago
|
||
Ok, What append here is that the copy operation of the sent message into the mailbox://sent folder failed because:
1) you don't have a local sent folder
2) or because you don't have a local mail account (pop3), you have only a imap account.
This is totally normal, it's a miss configuration. The solution is either to sole problem 1 or 2, or to set the
following prefs into the file prefs50.js to disable the copy operation:
user_pref("mail.default_fcc_server","");
Comment 9•26 years ago
|
||
Actually, to disable, set that pref to "nocopy://" not null...I wanted to error
on the side of safety (i.e. copy unless specifically told not to.)
- rhp
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
Assignee | ||
Updated•26 years ago
|
Target Milestone: M9
Assignee | ||
Comment 10•26 years ago
|
||
For clarification, set the following pref to disable the copy operation if your local mail account doesn't have a
"Sent" folder:
user_pref("mail.default_fcc_server","nocopy://");
Assignee | ||
Comment 11•26 years ago
|
||
set TM to M9
Comment 12•26 years ago
|
||
lchiang, do you agree that this is Invalid? Or is this still an open issue?
Comment 13•26 years ago
|
||
I'll read this more carefully later on - no time today.
Comment 14•26 years ago
|
||
Linux (1999-07-26-14 m9) and win_nt4.0 (1999-07-26-16 m9)
The Compose window does not close automatically upon Send. I think we should
keep this bug open
Comment 15•26 years ago
|
||
With discussion with Esther, we both have Sent folders in our pop accounts. Yet
the Compose window appears to re-open upon Sending. I don't know if Jay's is
the same scenario.
Reporter | ||
Comment 16•26 years ago
|
||
I used ducarroz's suggestion:
user_pref("mail.default_fcc_server","nocopy://")
and the problem went away...and to clarify, i originally reported this bug for
just win98...i never saw this problem on linux or mac. Also, i am sending my
messages from an IMAP account and i do not have a "Sent" folder...so this might
just be a misconfiguration problem like someone said earlier.
Assignee | ||
Updated•26 years ago
|
Target Milestone: M9 → M11
Assignee | ||
Comment 17•26 years ago
|
||
M11
Comment 18•26 years ago
|
||
Linux (1999-08-11-01 M9)
Reply compose window does not close either in both plain text and HTML windows.
Comment 19•26 years ago
|
||
Sounds like this needs to be fixed for PR1, so I added a note to the Status
Whiteboard
Assignee | ||
Comment 20•26 years ago
|
||
*** Bug 12668 has been marked as a duplicate of this bug. ***
Comment 21•25 years ago
|
||
(target milestone is M11 or M12 - add to mail beta tracking bug)
Updated•25 years ago
|
Summary: compose message window does not close upon sending message → Compose: if error sending, window doesn't close or display error
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 22•25 years ago
|
||
Should be ok now, we will always show an alert and then reopen the compose window (normal behavior).
Comment 23•25 years ago
|
||
Linux Redhat 6.0 (1999-11-01-08 M11)
Win_nt 4.0 (1999-11-02-09 M11)
Mac (1999-11-02-08 M11)
This problem has been fixed.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•