| Age | Commit message (Collapse) | Author |
|---|
|
minimizes the diff we need to keep. note that as previously mentioned
this requires mozilla>=85, but shouldn't cause issues unless called.
This partially reverts commit 553416c2d6d3c760cf98bd2c4afbaf0442321951.
|
|
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
|
|
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
|
|
makes LegacyFox compatible with Firefox 117.
regressed-by: https://bugzilla.mozilla.org/show_bug.cgi?id=1780695
see-also: https://hg.mozilla.org/mozilla-central/rev/911d540fce6f
|
|
regressed-by: https://bugzil.la/920187
|
|
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
|
|
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).
|
|
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.
|
|
this was never required.
|
|
This reverts commit 152b73585cf37a64b8022c8bd027587c9d9e511f.
|
|
This is outside the scope of LegacyFox and will be reverted. Only barely
tested.
|
|
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.
|
|
This broke installing some, but not all, addons. The reason is that some
addons derive their addon-id from a certificate's CommonName in
XPIInstall.jsm::loadManifest(aPackage, aLocation, aOldAddon)
|
|
|
|
Looks like all the settings continued to work by accident.
Note: out of scope for LegacyFox, but sideloading from anywhere can be
re-enabled by setting `SCOPES_SIDELOAD: 31 // AddonManager.SCOPE_ALL`.
|
|
regressed by: Bug 1524327
|
|
The wildcard will match both /usr/lib and /usr/lib64, so the Makefile
works on 99% of Linux distros. And yes, that's not what DESTDIR is for.
|
|
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
|
|
this hopefully makes the monkey patch update persistent.
Note: instead of using FileUtils, this would be another method:
const {Services} = Cu.import('resource://gre/modules/Services.jsm');
let manifest = Services.dirsvc.get('GreD', Ci.nsIFile);
manifest.append('legacy.manifest');
|
|
the chrome.manifest inside the install directory is not loaded any
longer by default; see bugzil.la/1543761
|
|
|
|
|
|
|
|
|
|
still has the mozillapath hardcoded, though
|
|
|
