TEXTAREA's and INPUT's leak one webshell each everytime a containing page is loaded/reloaded. (Although, for the INPUT's to leak you need to set focus to them.) To reproduce: 1. visit a blank page on browser startup and then exit. (Using a debug build) 2. notice the "XXX WARNING: Number of webshells being leaked: NUM" printed to stderr. Remember the number as a baseline. 3. restart the browser on a page just containing a <textarea></textarea> and exit. 4. notice the weshells leaked has grown by one. 5. restart the browser to the test page and then reload 10 times. When you exit you will notice the number of webshells leaked has grown by 10. 6. Also, if you make a page with several TEXTAREA's, you will notice each additional TEXTAREA adds an additional webshell leaked. NOTE: INPUT's work also (you just have to ensure each one is given focus to leak a webshell.

forgot to add 'mlk' to keyword field

assigning to Tony -- here is some memory leak stuff for you.

A little more observations... if viewer is used for the test, the webshell count is correct. The viewer doesn't report the total leaked, but the constructor/destructor for nsWebShell print the current count (and as you reload the page you can watch the proper number of decrements before reincrementing.

I've managed to narrow this down to auto detection of charactor sets. Last night I decided update my home machine's mozilla tree to the tip and rebuild. To my suprise I couldn't reproduce the leak! So then I telnet in to my work box and update/rebuild that tree again only to see the leak still exist. My next step was to tar up and download my work box's entire .mozilla directory for the user is was using. After replacing my local .mozilla with the downloaded one, the leak apeared on my local machine. (Ah! I'm not crazy!) After a little investigation I found that adding the line 'user_pref("intl.charset.detector", "zh_parallel_state_machine");' to my prefs.js will cause the leak described above. (In addition, three more webshells are leaked for just starting the browser on any page.) After a little more investigation I found that choosing auto dectection for any character set will reproduce this leak. So add an additional reproduce step to the ones above: 0.5) Startup the browser and choose any auto-detecting character set converters from the main menu by selecting "View"->"Character Coding"->"Auto Detect (whatever)" and then exit the browser. So, not that it looks like this has nothing to do with the editor should the "Component" be changed?

I've spotted a problem in nsHTMLDocument.cpp, so don't waste any time on searching for this guy. I will post a patch today.

for the above attachment: nsHTMLDocument.cpp: The root problem was that "nsIParserFilter * cdetflt" was being created in one location but being NS_IF_RELEASE'ed in another location that in most situations wasn't executed (because of an if() block.) The fix was to make a smart pointer out of it. Also, while I was in the code, there were three other objects queried from (or directly related to) the cdetflt object that were regular pointers. I went ahead an converted those to smart pointers. nsIParserFilter.h: The nsIParserFilter interface didn't have the macro for defining GETIID for whatever reason. I had to add the macro inorder for the smart pointer to build.

(Sorry to pick nits.) Let's use do_QueryInterface() instead of QI()-ing into an nsCOMPtr? Can you you give nsHTMLDocument.cpp one more round with do_QueryInterface()... thanks!

Checked in the patch with extra changes as specified from last comment.

This is no longer a problem since Ender lite landed. There is no longer a webshell per form text widget.