make compatible with mozilla142 and above

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

0 files changed, 0 insertions, 0 deletions