| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
for reference: https://searchfox.org/mozilla-central/source/xpcom/io/nsIFile.idl
|
|
the general idea came from onemen and 117649 in the discussion in
https://github.com/xiaoxiaoflood/firefox-scripts/issues/363 but the code
has been written from scratch (as I wasn't convinced of some of their
design decisions). in the end, the overall approach taken looks somewhat
similar, because there seems to be only one way to do that from JS code.
we only rewrite a subset of specified manifest instructions, that are
needed for VimFx. others are passed-through and might make other addons
work. the full list of manifest instructions is documented here:
https://www.devdoc.net/web/developer.mozilla.org/en-US/Chrome_Registration.html
Further notes on the implementation:
use of constants from (and hence import of) FileUtils has been avoided
by 1) specifying unix file/dir permissions directly instead of using
FileUtils.PERMS_FILE and 2) by relying on default open(2) modes in
FileOutputStream, which are the one we want anyways. its documented at
https://searchfox.org/mozilla-central/rev/4fd0d5e4669bfa2d0888b730684d8adea061fd30/netwerk/base/nsIFileStreams.idl#96-97
during uninstall(), it does not suffice to re-call .autoRegister() to
remove the chrome.manifest. .checkForNewChrome() has precedence in
mozilla-central:
https://searchfox.org/mozilla-central/rev/4fd0d5e4669bfa2d0888b730684d8adea061fd30/toolkit/mozapps/extensions/AddonManagerStartup.cpp#770
the file doesn't need to exist in uninstall() at all, and only the
parent directory must exist for install(), but creating it in both cases
simplified the logic a bit. an empty directory will stay behind in the
profile directory after uninstallation - oh, well; too bad.
nsIFile.remove() takes a boolean argument; it determines recursion.
https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/xpcom/io/nsIFile.idl#272
AddonManagerStartup exposes a method .registerChrome(), which takes a
parsed manifest instead of a file path. This one doesn't support 'skin'
entries (workaround-able with overrides) and does not expose 'content'
entries to the content processes - the latter kills this idea.
https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/toolkit/mozapps/extensions/AddonManagerStartup.cpp#782
https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/browser/extensions/formautofill/api.js#124
zipReader code was cribbed from here, with Cc[].createInstance()
replaced by the nicer Components.Constructor call:
https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/modules/libjar/zipwriter/test/unit/test_alignment.js#73
regressed-by: https://bugzilla.mozilla.org/show_bug.cgi?id=1953136
|
|
hg.mozilla.org now redirects to hg-edge.mozilla.org.
|
|
this also removes the reference to the long obsolete
https://hg.mozilla.org/mozilla-central/rev/061b97e02ede.
|
|
mozilla calls this 'esm-ification'. the last relevant to us modules were
ported in mozilla124[1], so this is our new minimum version. the old
version will likely be compatible with firefox up to version 128esr[2].
static imports are not supported in autoconfig scripts. i tried to keep
the diff as small as possible w.r.t comm-central's final JSMs. because
of this, we don't lazy-load any modules any more, nor provide any lazy
getters, as they would need to be loaded into a `lazy` object instead
the global (`this`) namespace, causing more churn. other than that, the
largest change was removing the now-useless Services.jsm workaround as
well as removing globalGetters for objects already loaded automatically.
[1]: https://hg.mozilla.org/mozilla-central/rev/68ba071ff6fb9978937496f9adc48e378957f594
[2]: bugzil.la/1881890
|
|
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
|
|
Services is only available in this scope since Bug 1667455 (mozilla104)
|
|
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
|
|
|
