fix setting softDisabled state not that it is too important. Blocklist.jsm does not export blocklist state any more. XPIInstall.jsm does this, since way before mozilla61: const { nsIBlocklistService } = Ci; addon.softDisabled = addon.blocklistState == nsIBlocklistService.STATE_SOFTBLOCKED; c.f. https://searchfox.org/mozilla-central/rev/b503616295d69fee56300e5e2093599e6fb4f0e2/toolkit/mozapps/extensions/internal/XPIInstall.jsm#531
remove OS.File references osfile.jsm was removed by bugzil.la/1772262. This method is not used any more, so we can just remove it. the modern alternative would be the following, but that only works on mozilla>=85. return IOUtils.writeUTF8(file, this.serializeToString()); osfile.jsm was loaded lazily (and in our case therefore never), so we didn't die immediately upon import, fortunately. see also: https://hg.mozilla.org/mozilla-central/diff/a11c616997d802e44d1afc0215bfbffac865179e/toolkit/components/passwordmgr/test/LoginTestUtils.jsm
remove use of deprecated components console.createInstance() is available since firefox59 (Bug 1425574), so no workaround needed. ChromeUtils.defineLazyGetter() however only is since firefox112 (Bug 1805288) but the backwards-compatible code is tiny see also: https://bugzilla.mozilla.org/show_bug.cgi?id=1875216 https://bugzilla.mozilla.org/show_bug.cgi?id=1430810 https://bugzilla.mozilla.org/show_bug.cgi?id=1828156 https://groups.google.com/a/mozilla.org/g/dev-platform/c/BdyWnTjLSXg
Fix bug in BootstrapLoader reported to https://github.com/xiaoxiaoflood/firefox-scripts/issues/115 > I just found that for my legacy addon after restart it some of it > function calls that initiated by timer or observer callback are > running in a sandbox context of the last startup which is different > from current one. And this cause malfunctions for my addon. see also: https://github.com/xiaoxiaoflood/firefox-scripts/commit/291bebc4f2edc919dd273f2cecbbfda61e157695
Do not override AddonSettings.REQUIRE_SIGNING This is not necessary, as it is only checked in XPIDatabase.jsm::mustSign(), which we can override instead, and in aboutaddonsCommon.js::isDisabledUnsigned(), which we cannot affect anyways and only uses it to show a red warning bar for legacy addons. This also removes the old AddonSettings.ALLOW_LEGACY_EXTENSIONS override, which was only used in Extension.jsm::experimentsAllowed() and XPIDatabase.jsm::isDisabledLegacy(). This is in preparation for the ESM-ification endeavours going on at Mozilla, which will make importing a module's global object (as we did with `let Xdb = Cu.import(...)`) impossible, but was needed to get a reference to AddonSettings (instead of a copy). Step two will be replacing Cu.import() with ChromeUtils.import(), which has stricter semantics about exported objects (doesn't hurt us; see Bug 1766114).
Revert "automatically disable signature requirement" downgrading the warning color stopped working some time ago. for completeness, as of nightly99 xpinstall.signatures.required is only checked in these places, none of which affect us: - nsContentSecurityUtils.cpp::DetectJsHacks() only for telemetry and relaxing some security measures we don't need - BrowserGlue.jsm::_onWindowsRestored() gates call to _notifyUnsignedAddonsDisabled(), which isn't triggered by our stuff (signedState != SIGNEDSTATE_MISSING) - AddonSettings.jsm::REQUIRE_SIGNING overridden by our config.js script, so doesn't matter - XPIProvider.jsm::observe() calls XPIDatabase.updateAddonAppDisabledStates(), which calls this.updateAddonDisabledState(addon), which depends on this.isUsableAddon(aAddon), which returns true as long as we override this.isDisabledLegacy(aAddon) This reverts commit 29dc0ab3a8f8bd6e781fb983cd076764480dce18.
automatically disable signature requirement Having signatures enforced causes a big red error message to appear below unsigned extensions, telling the user the extension has been disabled. This is not true, though; the extensions are still enabled. Setting xpinstall.signatures.required;false downgrades this error to a (yellow) warning.
switch to resource:// protocol bring the patch closer to the then-upstream comm-central. might have the negative side-effect of being detectable by websites according to: https://developer.mozilla.org/en-US/docs/Mozilla/Chrome_Registration