Build tested: Mac Seamonkey build 1999-09-16-08-m11 installed on - G3/400 MacOS 8.5.1, G3/400 MacOS 8.6 and, PPC 7500/100 MacOS 8.5.1. Description: The mail compose window fails to close when you click on the window close box or using the File|Close menu option. The application is not frozen but you can not type in the compose window and the menus become scrambled (partial listing). The behavior of the problem will give people the impression that the application is frozen when the compose window does not render properly and display an empty window. Work around: close the all the other open apprunner windows (browser, messenger, etc). The compose window will close. Steps to reproduce problem: (There are a couple of ways in seeing this problem) 0) I had my user_pref for compose_html set to true. 1) Start Apprunner 2) Open the Messenger window 3) Click the New Msg button A HTML mail compose widnow appears 4) Click on the close button or use the File menu 'close' option. The window does not close Actual results: The windows does not close. It looks like the application has locked up. You can switch to the browser or messenger window. You can start another mail compose window. Expected results: The mail compose window should close. Other platforms tested: This problem occurs only on the Mac. It does not occur on win32 1999-09-16-08- m11 build or on linux 1999-09-16-08-m11 build. Additional information: This problem does not occur if you start apprunner with the compose mail parameter to bring up only a mail compose window. This problem is reproducible if you start apprunner with '-mail' parameter or just starting the browser.

This bug is different from bug 12994 because you don't type anything in the compose window. You bring it up then close it (at least try to). I tried to set the focus in the email address field but it does not appear to have an effect.

cc danm, you might contact him directly, since he gets more bug notifications than he can keep up with.

If I remove all the tag html:select from the addressing toolbar (I deactivate the corresponding JS), I don't see the problem anymore. Something going wrong with dropdown list on Mac! Reassign to rods.

Don, Mac specific combobox problem, can you take a look?

*** Bug 14515 has been marked as a duplicate of this bug. ***

*** Bug 14398 has been marked as a duplicate of this bug. ***

It looks like nsHTMLInputElement are being leaked here, possibly because the nsComboboxControlFrame is holding extra references to them.

I think I've figured out part of this. Please see bug #14687

I found one place where we weren't doing a release and in the testing I did it didn't hit that code. Also, I walked through the selecting of an item in the combobox and couldn't find where we where addrefing and then not releasing. So I don't yet understand why Simon thinks we are holding onto a reference. Simon, where did you find that?

First, I know that we're leaking nsHTMLInputElements, because I had a breakpoint in the dtor, and never hit it. I'm a little concerned by the NS_ADDREFs on lines 1230 and 1243 of nsComboboxControlFrame.cpp, because NS_NewHTMLInputElement() returns an element whose refCount is already 1, and there is no corresponding release. But even if I comment these out, the nsHTMLInputElements don't get freed.

Thanks for finding the addrefs. When I comment out the two extra addrefs I get breaks points fired in the nsHTMLInputElement and one in the nsHTMLSelectElement.

With the extra AddRefs commented out on Mac, the nsHTMLInputElements do indeed get released. The zombie window, however, remains, even when the user has not clicked on the combobox.

How are we doing on this bug?

I still have the problem with today's build! This bug should be a M10!

*** Bug 15024 has been marked as a duplicate of this bug. ***

I think this crashes because of the nsDeleteObserver.. Pierre says he has a fix so I am waiting on that to see if that clears this up. Also the leak fixes seems to make this bug crash less.. not as frequent, but I can still get a crash so I will wait for the other fix to see how that does.

Could you try the following? In nsMacEventHandler::~nsMacEventHandler() and nsMacEventHandler::NotifyDelete(void* aDeletedObject), do: mLastWidgetPointed = nsnull; mLastWidgetHit = nsnull;

I forgot to mention that the above was for the crash only, not for the zombie window. For more info, look under #14775.

The following HTML causes a crash due to the nsDeleteObserver destruction if you click on the combobox only. It wont crash if you dont click on box. Pierre can you look at this and see if you see anything obvious in the deleteObserver class. Also are there any Mac tools the help detect leaks. <html> <head> <title>Mac Combo Box Test</title> </head> <body> <H1> Mac Combo Box Test</H1> <form> <select Name="hcolor"> <option> Black <option> Blonde <option> Brown <option> Red <option> Blue <option> Gray <option> Yellow <option> Sandy <option> messy <option> stripped </select> </form> </body> </html>

I have a fix for #14775: it doesn't crash anymore with the Editor, the Installer or the combo boxes. However, it did not fix the bug with zombie windows described here. That's a separate problem... I'll have a look.

I have a fix for the zombie windows too: WidgetToScreen and ScreenToWidget are leaking the parent window when they go into recursion.

Fixed

*** Bug 14396 has been marked as a duplicate of this bug. ***

Reopening to get fixes checked into the M10 branch. Pierre, if you have done this, then please re-close the bug.

mr. leaf migrated pierre's changes to the m10 branch. some reviewer eyes on his merge would be a good deed. http://cvs-mirror.mozilla.org/webtools/bonsai/cvsquery.cgi?treeid=default&module =SeaMonkeyAll&branch=SeaMonkey_M10_BRANCH&branchtype=match&dir=&file=&filetype=m atch&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=% 2Fcvsroot marking fixed so this gets in the m10 testing queue

*** Bug 15444 has been marked as a duplicate of this bug. ***

Verified as fixed using the Mac commercial build 1999-10-01-20-m10 build. I can successfully close a messenger compose window, account set up dialog, and new folder dialog.