Created attachment 621945 [details] [diff] [review] Patch
Thanks for filing the follow-up bug.
Comment on attachment 621945 [details] [diff] [review] Patch r=me
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 ...
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.)