Mozilla's helper apps (GPU, content, etc.) use the hardened runtime and
Mozilla's Team ID, so in unsigned builds they couldn't load our custom
libmozglue.dylib and failed to launch. Re-sign them ad hoc.
mozinference (which is currently CPU-only) is better for many tasks, but
plugins may want WebGPU for some features (e.g., chatbots), so just
follow Firefox, which currently enables it by default for Windows and
Apple Silicon macOS. Adds 5.8 MB compressed to the Windows installer.
Skip crashhelper (all platforms -- the crash reporter is disabled) and
desktop-launcher and nmhproxy.exe (Windows).
Also skip dxcompiler.dll (Windows, 22 MB), which is loaded only by
WebGPU, now also disabled via pref. Nothing renders with WebGPU, and
local ML -- including any future plugin API -- should go through
Firefox's inference libraries (mozinference/onnxruntime), which are
compiled CPU-only.
Firefox 153 removed the chrome://browser/skin/window-controls/ SVGs and
now draws the caption buttons with Segoe Fluent Icons glyphs (falling
back to Segoe MDL2 Assets on Windows 10), which broke the Windows build.
Port the new browser.css button styling and stop keeping the removed
directory in build.sh.
Babel strips the trailing newline from defaults/preferences/zotero.js, so
the platform-specific prefs appended after it shared a line with the last
Zotero pref.
SelectableProfile.sys.mjs now statically imports BackupService, which
statically imports chrome://browser/content/backup/backup-constants.mjs,
so startup failed once SelectableProfileService was instantiated as a
command-line handler.
Developer ID-signed Safari web extensions load only in Safari 18.4 and
later -- older Safari blocks them at the code-signing layer -- so macOS
11 and 12 users, whose Safari versions top out at 16.6 and 17.6, lost
the connector with the web extension conversion.
Embed the prebuilt legacy App Extension ($SAFARI_APP_EXTENSION, set by
the deploy scripts) at Contents/PlugIns/ZoteroSafariExtension.appex with
the historical bundle identifier, and move the web extension to
Contents/PlugIns/ZoteroSafariWebExtension.appex with a new
.SafariWebExtension identifier. The web extension's
SFSafariAppExtensionBundleIdentifiersToReplace key causes Safari
versions that can load it to hide the App Extension and migrate its
enabled state, while older Safari shows only the App Extension.
Also remove the removed-files entries for the App Extension's
resources, which would otherwise delete them on update.
https://forums.zotero.org/discussion/132925/
The connector is now a Safari web extension, so the bundled appex is a
static wrapper stub whose placeholder resources are replaced at build
time with a connector build via $SAFARI_EXT_RESOURCES. The stub only
needs to be rebuilt when the native wrapper project changes, not for
connector releases.
JNA 5.x ships per-architecture macOS native libraries instead of a
single com/sun/jna/darwin/ directory, so the notarization re-signing
step failed with "filename not matched".
This step can be removed entirely once the plugin ships a jna.jar
without the macOS natives, which are never loaded.
`fetch_xulrunner`, `dir_build`, and `build.sh` now take an optional `-a`
argument on Windows and Linux to specify the architecture to
fetch/build. If `-a` is omitted for `dir_build` (as in `build_and_run`),
it defaults to the current architecture.
xulrunner hashes are now computed for each architecture. This changes
some filenames in xulrunner/, so you may want to clean out some old
folders/files.
This removes the custom handling for CI, since it will now default to
the architecture of the test runner.
After further consideration, doing this in-app makes more sense. This
way, we'd never be able to update the desktop file automatically (e.g.,
to add a new MimeType), and removing the template zotero.desktop file
would break all existing installs using our symlink instructions.
In-app, we can update the existing desktop file on restart after an
upgrade, and we can remove the existing symlink.
This reverts commit 0ac57f8262.
Mac Firefox builds now specify the update channel via a custom macOS
framework:
https://bugzilla.mozilla.org/show_bug.cgi?id=1799332
We set the update channel in the build script, so bundle a custom
ChannelPrefs framework set to "source" and then patch the binary as
necessary for non-source channels. What could go wrong?
LightweightThemeConsumer interacts with the color scheme,
so disabling it prevents the color scheme from changing
whenever zoteroPrint runs.
Fixes: #4782
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)
