CBrowserContainer's mRefCnt never goes to 0

RESOLVED FIXED

Status

Core Graveyard
Java APIs to WebShell
P3
normal
RESOLVED FIXED
17 years ago
5 years ago

People

(Reporter: edburns, Assigned: edburns)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Assignee)

Description

17 years ago
DocumentLoadListenerImpl mRefCnt never goes to 0
(Assignee)

Comment 1

17 years ago
I filed, I accept
Status: NEW → ASSIGNED
(Assignee)

Comment 2

17 years ago
Changed Summary.  DocumentLoadListener is no longer in webclient.
Summary: DocumentLoadListenerImpl mRefCnt never goes to 0 → CBrowserContainer's mRefCnt never goes to 0
(Assignee)

Comment 3

17 years ago
Created attachment 11856 [details]
Research document.
(Assignee)

Comment 4

17 years ago
Created attachment 11866 [details] [diff] [review]
Fix for this bug, first iteration.
(Assignee)

Comment 5

17 years ago
Created attachment 11867 [details] [diff] [review]
Fix for this bug, first iteration, Unified diff.
(Assignee)

Comment 6

17 years ago
bug=41871

This checkin makes it so CBrowserContainer is properly released.  The
problem was that the CBrowserContainer was still registered to the
docShell as a listener.  The solution was to call
wcIBrowserContianer::RemoveAllListeners() in the WebShellInitContext
deallocator.

(Assignee)

Comment 7

17 years ago
Created attachment 11870 [details]
Research document, with comments.
(Assignee)

Comment 8

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Component: Java APIs to WebShell → Java APIs to WebShell
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.