Also:
- Hide format options until translators are loaded (since otherwise
the checkboxes don't have labels and the layout is messed up)
- Remove unnecessary "zotero-" prefix from the new elements
The default JSON pref value used spaces, but changing the drop-down
resulted in a version without spaces, so simply changing the default to
include the new link options wouldn't change all existing installs and
the "Include App Links" checkbox wouldn't show as enabled for Markdown.
This adds a pref migration step to reset the pref to the new default if
it's set to Markdown + Rich Text, regardless of whitespace differences.
And just fully reload the preferences window when the pane array changes. The
preferences window won't often be open when a plugin is enabled or disabled,
considering that the Add-ons window is external to the preferences, and trying
to add/remove panes dynamically without reloading brings lots of bugs.
(No way to dynamically remove a script, for one.)
People are confused by "Zotero Connector Server is Available". I'm not
sure if this will be any better, but not mentioning the connector might
help -- that seems to be part of the problem.
We could display a longer message with a link to
https://www.zotero.org/support/kb/connector_zotero_unavailable, but this
is the /ping page that gets hit constantly, so it seems like we should
keep it short (though probably it doesn't make a difference).
- Word for Windows not tested since there's no build yet
- Word for Mac currently causes a sigsev, and likely we'll see this on
windows too. This is happening on an API call where we pass a callback,
so likely an issue in ctypes that we'll have to work around.
- All integration UIs restored.
- Added a component for richlistitems with a checkbox with corresponding
interactions (spacebar/double-click to toggle).
Fixes the issue when your own created annotation becomes grayish and indicates that it was modified by another user.
(cherry picked from commit 4dd1851140)
Having the macOS Help button in a scrolling view feels kind of weird, but that's
what Apple is doing in the Ventura System Settings app, so I guess we go with
it. I like it better than Firefox's non-contextual "Firefox Support" button
under the pane list in their preferences, anyway - having pane-by-pane
contextual help buttons seems like good UX that there isn't a good reason for us
to ditch.
- The protocol can no longer be marked "dangerous to load," only "UI resource"
(accessible inside browsers but not by web pages).
- The protocol needs to run in the main process.
- We need to replace the XUL browser to reset its type attribute depending on
whether we're loading a zotero protocol URI - zotero protocol URIs, maybe due
to the protocol handler's tight coupling with the main process, cannot load in
type="content" browsers.
