So apparently add-on folks are footgunning themselves on Cu.unload (cf. bug 1287824 ). We should take away the footgun.
Once you have system principal and access to Cu, you have access to all the footguns of the world. We can only make it harder for add-ons to do this, won't be able to completely prevent it. Is you intention to prevent the unintentional cases? For that, a warning should be enough if the caller scope is an add-on scope. I'm not against that.
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #1) > Once you have system principal and access to Cu, you have access to all the > footguns of the world. We can only make it harder for add-ons to do this, > won't be able to completely prevent it. Well, there are no cases that I can see in our codebase where we use .unload with core app files, outside of tests (which we could fix). I'm not sure why such functionality would be necessary. > Is you intention to prevent the > unintentional cases? For that, a warning should be enough if the caller > scope is an add-on scope. I'm not against that. Well, "intentional" is an interesting word. I guess I'm alleging that nobody who actually understands what Cu.unload does would ever want to Cu.unload a module from resource:/// or resource://app/ or resource://gre/ in a running Firefox instance. Which then by definition makes all the current callers "unintentional". I don't think a warning is good enough, because the MDN page for Cu.unload already has a warning, and clearly people aren't reading it, if even people in MoCo itself ( https://github.com/mozilla/universal-search/issues/267 ) are using it to unload core Firefox files from add-ons... :-\
Any thoughts, Bobby (feel free to say no)?
Priority: -- → P3
Happy to add any restrictions that lead to less bugs in practice. This API is YMMV anyway.
You need to log in before you can comment on or make changes to this bug.