Show an appropriate error if the ARM64 installer is run on non-ARM
Windows or if the x64 installer is run on a 32-bit system, and set the
correct architecture in `CurrentVersion\Uninstall` registry key.
Also fix `x86`/`x64` being swapped in the registry
(https://groups.google.com/g/zotero-dev/c/1Aju4t2TNTo/m/Ga4V8vLrAQAJ)
Mozilla uses a `precomplete` file to delete local files when doing a
complete update, but since Zotero 5 in 2017 we've just been bundling an
empty file, which has meant that deleted or moved files have been left
behind. Among other things, this has likely been the primary cause of
Safari App Extension post-update brokenness for many years.
Incremental updates weren't affected, since those include explicit
removal instructions for moving from the given build to the latest one.
This restores proper generation of the `precomplete` file during builds,
using the Mozilla script added in 74ec6620e.
Separately, we'll update the `removed-file` for each platform to remove
files that should've been removed during previous updates.
Fixes#3133
Since -jsdebugger apparently works fine, there's no reason to connect to
Zotero from Firefox anymore. So just open the Browser Toolbox when
passing the -d flag to build_and_run, and stop having the devtools
server listen on port 6100 for devtools-enabled builds, since
-jsdebugger uses a random port of its own.
(Or technically 125, but I don't think any strings we need were
removed)
This fixes the Edit and Window menu (except for some macOS Window
strings that seem to come from the system) in non-English locales.
The `app/win/codesign` script should take a path to a file and a
description (`/d` parameter to `signtool.exe`) and sign the file using
whatever process the certificate authority requires.
Unimplemented:
- ARM-native installer/uninstaller
Untested:
- Installer/uninstaller/updater
- Word integration DLL
Also updates the launcher and updater to 115.9.0esr for x64. win32 stays
on 115.4.0esr for the launcher and 102.11.0esr for the updater because I
can no longer build it.
After the removal of zotero-service.js for fx115, we no longer have a
`components` folder, so we don't need to shuffle things around to merge
our folder with the one from Firefox.
This fixes a build failure we were getting in CI after #3894.
XPCOM objects have to be statically registered now, so instead of
creating our own command-line handler, just stuff our code into the
Firefox one.
A few parameters require the Zotero object, which isn't available in the
Firefox CLH, so I've left those in zotero-service.js for now until we
decide how to deal with those.
We were previously using an old version of the Mozilla updater before they
added Mozilla signature verification, but it's Intel-only, so we need to build
our own version of the current updater with signature verification disabled.
All declared Fluent files need to exist for a locale to be used (in a
window?). Since Mozilla code tries to load Fluent files, we need to copy
non-English Mozilla .ftl files to their default effective path (just in
the app omni.ja instead of the toolkit omni.ja).
Fixes#3094
