47041 - Unable to unregister an HTTP Notify listener

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P3)

Description

[Thomas Lendacky]

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (WinNT; U)
BuildID:    

The UnregisterModule function of nsNetModuleMgr.cpp does not unregister an HTTP 
Notify listener properly.  There are two problems related to this function, both 
of which exist within the nsNetModRegEntry.cpp Equals function:

1. The PL_strcmp should be compared to 0 since you want to process the 
unregister if the topics are identical.

2. Once the PL_strcmp succeeds, there is a comparison between aSyncProxy and 
mSyncProxy.  However, mSyncProxy is always 0 and the call to GetSyncProxy prior 
to this comparison creates an aSyncProxy and returns a non-zero address.  So, 
the aSyncProxy and mSyncProxy never succeeds.

Reproducible: Always
Steps to Reproduce:
1. Call the RegisterModule function of nsNetModuleMgr to register an HTTPNotify 
listener.
2. Call the UnregisterModule function of nsNetModuleMgr to unregsiter the 
HTTPNotify listener.  It won't get unregistered.

Actual Results:  The HTTPNotify listener is never unregistered and continues to 
receive notifications.  Since I register/unregister whenever I perform a load 
for a URI I end up with many, many copies of listeners getting called.  This 
causes increasing memory usage and slows the performance since all the 
HTTPNotify listeners have to be invoked.

Expected Results:  The HTTPNotify listener should have been unregistered.

Comment 1

[Gervase Markham [:gerv]]

Confirming for evaluation.

Gerv

Comment 2

[Gagan]

Tom are you blocked on this for anything critical? If not then we'd have to move 
this to future. 

Comment 3

[Thomas Lendacky]

I'm not blocked in that I can still code and test and everything seems to work 
fine.  However, I don't know what the impact will be if extensive use of the 
browser was performed.  There could be literally hundreds of listeners 
registered that have to get called before the data could be passed on to the 
parser/layout engine.  This really needs to be fixed, but since the P3P support 
that I'm working on will most certainly not be part of the first Netscape 
product, it can wait.

Tom

Comment 4

[Gagan]

pulling in ruslan's necko bugs ->darin

Comment 5

[Gagan]

http bugs to "Networking::HTTP"

Comment 6

[Darin Fisher]

Attachment: fixes the PL_strcmp brain fart

Comment 7

[Darin Fisher]

not sure how this patch got lost... will try for 0.9.4

Comment 8

[Darin Fisher]

Attachment: v1.0 more complete fix

Comment 9

[Bradley Baetz (:bbaetz)]

r=bbaetz

Comment 10

[Doug Turner (:dougt)]

sr= me.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc+moz on behalf of drivers

Comment 12

[Darin Fisher]

fixed-on-trunk

Comment 13

[Tom Everingham]

verified:

Win NT4 2001-09-24-05-0.9.4