1288397 - Disallow (or add a 'force' parameter to Cu.unload to allow this) unloading anything under resource://gre/ or resource:/// or resource://app/

Status: REOPENED

(Core :: XPConnect, defect, P3)

Description

[:Gijs (he/him)]

So apparently add-on folks are footgunning themselves on Cu.unload (cf. bug 1287824 ). We should take away the footgun.

Comment 1

[Gabor Krizsanits (INACTIVE)]

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.

Comment 2

[:Gijs (he/him)]

(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... :-\

Comment 3

[Andrew Overholt [:overholt]]

Any thoughts, Bobby (feel free to say no)?

Comment 4

[Bobby Holley (:bholley)]

Happy to add any restrictions that lead to less bugs in practice. This API is YMMV anyway.

Comment 5

[BMO Automation]

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.