On browser startup, a webshell is leaked when running mozilla, but not viewer. Also, if auto-detection for character sets is turned on, two webshells are leaked. To reproduce: 1. Startup the browser on any webpage (even about:blank) on a debug build. 2. exit and notice the debug message for the number of webshells leaked. On at least Linux and Mac, a single webshell is leaked if character set auto-detection (as controled from the 'View'->'Character Coding' menu item) is turned off, but two shells leak if any character set auto-detection scheme is turned on. NOTE: At least on Linux, viewer does not leak any webshells using the same test case.

Actually, this bug covers more then one bug. One of the webshell leaks is dependant on character set auto-detection being turned on, it is reproducable even on about:blank. That bug is covered on bug #40149. Although, even after #40149 is fixed as described in the bug report, another webshell leak exist indepenant to character set auto-detection if a page other then about:blank is visited. I opened 10 top level windows from the 'File->New Navigator Window' menu and observed 5 webshell leaks on exit. NOTE: The above test are after the fixing patch at bug #39796 has been applied to cut out some other webshell leaks.

Ok, found the problem. The reason this webshell leak doesn't show up in viewer is because viewer doesn't use cache (since viewer currently doesn't know where to find the cache directory.) The problem comes up when the cache manager isn't able to initialize a new listener in nsCachedNetData::InterceptAsyncRead() to replace the original listener. A listener was directly created with a 'new' call, but if a call to the listener's Init() method fails, the InterceptAsyncRead() just returns Init()'s return value, forgeting about the newly created listener. Also, while I was rooting around in the protocol code looking for this guy, I found a small problem in nsHTTPChannel.cpp that complicates the matter. (Basicly, since InterceptAsyncRead() wasn't deleting the foobar listener before returning a failure code, a call from the channel code that ignored the return value and instead just tested for a non-null listener was fooled into thinking the cache manager was successfull.) This bug also shed light on another elusive bug, the cache is getting corrupted somehow on (at least) a couple of my Linux builds (but not the one off the tip). After all, if the cache works without a problem, the webshell leak will not show up. So, if you want to expose this webshell leak, you need to screw up the cache. (I've found that playing with the file permissions does the trick.) I am attaching a patch.

changed component to Networking:Cache

Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

Can you reattach your patch? I cannot open it Thanks, Neeti

It looks like some other people have been duplicating effort at bug #41172 *** This bug has been marked as a duplicate of 41172 ***

for http r=gagan

patch checked in for http code.

my bad. See bug 43958 for the corrected HTTP patch.