Cut wrappers after firing [inner,outer]-window-destroyed.

RESOLVED FIXED in mozilla15

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: khuey, Assigned: khuey)

Tracking

unspecified
mozilla15
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 621945 [details] [diff] [review]
Patch
Attachment #621945 - Flags: review?(bzbarsky)

Comment 1

5 years ago
Thanks for filing the follow-up bug.
Comment on attachment 621945 [details] [diff] [review]
Patch

r=me
Attachment #621945 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/0868da9fac99
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
My tiny brain cannot handle this bug's pithiness.  Which problem does it address?
Before this fix we'd post an async event to the event loop, then cut the wrappers from chrome to content.  When the event fired some time later, we'd send a notification to chrome that the window is going away.  Some chrome (including old addon SDK versions) would then try to run cleanup code that touched the window, and this code would throw because the wrappers had been neutered.

This fix just moves the neutering of the wrappers to run right after the notification, from the async event.
Thanks!  So bug 751466 is less urgent now, good.
That was the idea, yes.  ;)
But we should perhaps put that information in that bug.  Kyle, want to do that, since you did the actual testing here?
I think I already did that in comment 31 ...

Updated

5 years ago
Depends on: 753621

Comment 10

5 years ago
Any chance to to get this solution (and the under-laying bug 695480) elevated to Aurora (mozilla14) ?

With this fix, the win in term of memory and leaks is so much greater than the hassle of (some) breaking Add-ons.

Please correct me if I'm wrong.
Bug 695480 (and this one as a followup) is quite risky change, so getting it to Aurora
isn't likely.
> Any chance to to get this solution (and the under-laying bug 695480) elevated to Aurora (mozilla14) ?

Lots of bugfixes landed after bug 695480 -- see the list of dependent bugs.  So there's really no way we're going to port this up to Aurora.
And bug 695480 is a big enough change that we want a full development cycle to shake out any problems it causes.  (This very bug is a perfect example of the kind of problem we need to shake out.)
You need to log in before you can comment on or make changes to this bug.