Closed
Bug 1355215
Opened 9 years ago
Closed 8 years ago
Cu.unload should nuke the compartment
Categories
(Core :: XPConnect, enhancement, P2)
Core
XPConnect
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mccr8, Unassigned)
References
Details
The unload() method, surprisingly, does not unload anything. All it does is remove the registration of the resource, and drop the rooting of the compartment by the XPConnect component manager. If anybody else has a reference, it will stay alive. What is worse, if somebody later imports the same resource, it will end up creating a new compartment. This makes it a bad idea to use for anything like bug 1354820 that may end up repeatedly importing and unloading a resource.
We should just nuke the compartment, now that we have that as an option. I think it will match better with what somebody might expect when calling a method named "unload".
|
||
Updated•9 years ago
|
Priority: -- → P2
|
||
Comment 1•8 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INACTIVE
|
||
Updated•8 years ago
|
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
|
|
||
Comment 2•8 years ago
|
||
I intentionally left this closed. We can't do this anymore, since JSMs no longer get their own compartment, just an NSVO in a shared JSM global. And Ted is working on moving them to ES6 modules, which have similar constraints.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•