Closed Bug 231435 Opened 21 years ago Closed 21 years ago

compose window won't close


(MailNews Core :: Composition, defect)

Not set


(Not tracked)



(Reporter: mrmazda, Assigned: grajaman)




(2 files)

OS/2 trunk 2004011808. IIRC, Friday the 16th was OK, and this started on the 17th.

To reproduce:
1-compose or reply to a message
2a-attempt to close the window (click X widget), or
2b-attempt to send (click send button)

Actual results:
1a-window does not close, or
1b-message is sent and copied to sent folder, but window does not close

Expected results:
1-compose window closes

1-The compose window can be closed, but only by exiting Seamonkey entirely.
2-I normally compose and send in plain text format. I only tried sending with my
normal profile, not killing any messages prior to sending. A brand new profile
did not change the behavior.  With the new profile, I didn't bother to change
any prefs, and when the compose window came up in the HTML editor, I tried,
unsuccessfully, to close the window immediately.
3-The window remaining is not complete. After hitting send, the message body, 
destination, and subject fields are emptied, and portions of chrome are corrupted.
I confirm this on Thunderbird 0.5a
This message appears in the JavaScript console :

Error: gMsgCompose has no properties
Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 2096
What OS are you running Thunderbird 0.5a on?
Oh sorry. It's on Linux.
Christian & David, are you not seeing this on something other than OS/2? Do
comments 1 & 3 indicate this isn't OS/2-only?
No, can't confirm with 20040119 on Linux or Win98.
No improvement in 2004011908.
I tried 2004011908 tar.gz on Fedora Core and couldn't duplicate the problem.
In this morning Thunderbird build on Linux the problem is still here with this
error messages in the JavaScript console :

Error: gMsgCompose has no properties
Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 2101
This is working fine on 20040116 and fails after that. I am now going to narrow
down the bug which introduces this bug. 
Assignee: sspitzer → grajaman
my guess would be this bug:

It messed with prefs, and one of the prefs it messed with is reuse mail window.

Maybe something strange happened.
this works fine on both seamonkey and thunderbird for me. Do you have re-use
compose windows turned off?
In my user.js is:
     // user_pref("mail.compose.max_recycled_windows", 0);

about:config shows mail.compose.max_recycled_windows default integer 1

The new profile I created to test this had absolutely nothing changed from the
Changing mail.compose.max_recycled_windows from 1 to 0 solves the problem.
The following pref is missing in the current nightlies which could be causing
the problem
pref ("mail.compose.max_recycled_windows",0). 

This could be because of the bug #224578. We might need the following unix
specific fix for OS/2 aswell
Kaply, let me know what do you think?
we should just add the recycled windows pref to os2pref.js for now.
and shouldn't the value be 1, so that we cache one compose window?
OS/2 can't cache compose windows at all last time I checked. We had trouble with
the concept of a half used window around - the user could still get to it
There is no os2pref.js in the present nightlies. Looks like all platform
specific *pref.js files have been removed and the files (preferences)  are made
global. So might have to do #ifdef XP_OS2 in mailnews.js itself?.
yep, that's what we should do.
Attached patch Patch for reviewSplinter Review
Did you test this and verify it worked?
Yep I verified.
Comment on attachment 140042 [details] [diff] [review]
Patch for review

r=mkaply, sr=blizzard (platform specific code)
Attachment #140042 - Flags: superreview+
Attachment #140042 - Flags: review+
Fix checked in.
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 232921 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.