Closed
Bug 536486
Opened 15 years ago
Closed 14 years ago
ClearMouseCapture seems to leak gCaptureInfo.mContent
Categories
(Core :: Layout, defect, P2)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta1+ |
People
(Reporter: bzbarsky, Assigned: enndeakin)
References
Details
(Keywords: memory-leak)
Attachments
(1 file)
1.31 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
From mail to Neil and his response: > Neil, > > I'm trying to understand the ownership model of gCaptureInfo.mContent. Why > does PresShell::ClearMouseCapture sometimes release it and sometimes not? > Can this not lead to leaks? I'm especially looking at the > IsDestroyingFrames() codepath. Looks like that path should be releasing mContent as well. Overall, ClearMouseCapture should always be releasing unless the captured content is outside the view passed in.
Assignee | ||
Comment 1•15 years ago
|
||
Considering bug 500882, the IsDestroyingFrames check could just be removed. It's only there to avoid an assertion. mContent will end up getting cleared if it has no frame in the next code block.
See also bug 524037.
Assignee | ||
Comment 3•14 years ago
|
||
Attachment #419418 -
Flags: review?(roc)
If it's avoiding an assertion, we can't just remove it.
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #4) > If it's avoiding an assertion, we can't just remove it. The assertion (from nsFrameManager::GetPrimaryFrameFor) no longer exists.
Comment on attachment 419418 [details] [diff] [review] remove this check Ah great :-)
Attachment #419418 -
Flags: review?(roc) → review+
Assignee | ||
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
http://hg.mozilla.org/mozilla-central/rev/53f1d5a8c171 was the changeset
blocking2.0: ? → beta1
Priority: -- → P2
You need to log in
before you can comment on or make changes to this bug.
Description
•