For a dependent CSL style with no default-locale of its own, citeproc-js
parses the parent's XML and silently uses the parent's default-locale
over any user-selected locale, making the locale dropdown a no-op. Add
a Zotero.Style.effectiveLocale getter that falls back to the parent's
locale, and use it in updateLocaleList and the locale-selector custom
element to disable the dropdown in that case.
https://forums.zotero.org/discussion/comment/512891/#Comment_512891
The general HTTP layer's automatic 429/Retry-After retry only retries
the one failed request, but the sync layer wants to pause its entire
batch of concurrent requests via concurrentCaller.pause(). Add a
noRetryOnThrottle option to Zotero.HTTP.request() that throws on 429 or
503 with Retry-After so the caller can apply its own throttling, and
have syncAPIClient set it. Extend sync's catch block to also honor
Retry-After on 503 (previously only invoked via _check429).
When a user's account is deleted and then undeleted on the server, the
dataserver creates a fresh shardLibraries row at a low version, while the
client still has a much higher local library version. Subsequent syncs
then throw "_libraryVersion cannot decrease" and the user is stuck.
Tag the cannot-decrease errors from the library version setters with a
named error, catch it in Engine.start(), reset libraryVersion and
storageVersion to -1, and restart. The retry hits the existing
libraryVersion == -1 branch and runs _fullSync(), which re-uploads the
local library against the recreated server library.
Previously only 503 + Retry-After was retried automatically; 429 was
handled only inside the sync API client. Extend _retryOnServerError()
to also retry on 429, honoring Retry-After on both 429 and 503 and
falling back to the existing exponential backoff otherwise.
In list mode, sort libraries by the count of their items
cited in the current document, falling back to alphabetic sorting
when counts are equal, with "My Library" always getting
priority over other groups.
Fixes: #5924
The test opened an advanced search window but never closed it, which
likely caused the intermittent failures in the ZoteroPane focus() test
"should shift-tab across the zotero pane".
Ignore persisted compatibility flag from previous app version in non-stable releases to fix disabled for wrongly using old flag
Ignore max version compatibility for plugin update check on non-stable releases
Relevant: https://forums.zotero.org/discussion/131096/
---------
Co-authored-by: Dan Stillman <dstillman@zotero.org>
Before the refactor, main library column prefs were keyed under
"<id>-default", because the visibilityGroup getter returns 'default'
(truthy) for the main library. The refactor changed the suffix logic to
only append non-default groups, leaving existing prefs orphaned at
"<id>-default" while the new code reads/writes "<id>".
Fall back to the legacy key on load when the new key is missing or an
empty object (which can be written out by an unmodified post-refactor
build that flushed prefs on a visibility-group switch, like switching to
feeds), and drop the legacy key on the next write.
https://forums.zotero.org/discussion/131202/lost-columns-displayed-choice-in-the-items-tree-after-update-to-10-beta-4
Covers the regression fixed by a7d001fc1d. The prior test for
_setHighlightedRowsCallback() called the callback directly, bypassing
the focus check and the keydown handler.
After the item tree refactor, the items tree id became "item-tree-main"
instead of "item-tree-main-default". Update the remaining call sites,
restoring collection highlighting on Ctrl/Option, focusing the item tree
after Add Item by Identifier, and Shift-Tab focus movement from the item
tree to the toolbar (which only still worked due to the native tab
order).
HTTP.download() was rewritten in 0fe31b0f04 to use fetch() and build the
Basic auth header itself via btoa(username + ':' + password), but the
username and password come from nsIURI.username/password, which are
percent-encoded. As a result, a username like "user@example.com" was
sent as "user%40example.com", causing a 401 on every WebDAV download for
any user with @, :, space, etc. in their username. Other request types
were unaffected because they go through xmlhttp.open(method, url, true,
username, password), which decodes internally.
Decode username and password in _parseURI() so the values returned can
be used directly for Basic auth (and as a side effect, fix the other
display/use sites that were getting the percent-encoded form).
https://forums.zotero.org/discussion/131174/zotero-10-betas-1-2-3-cant-download-from-webdav-http-401
Use one registry to avoid competing of language detect between plugins,
as resources declared as optional is identical to resource missing and thus fails the check and returns null for the string (https://searchfox.org/mozilla-esr140/source/intl/l10n/rust/l10nregistry-rs/src/registry/asynchronous.rs#140)
Register the plugin FTL for all languages Zotero supports with proper fallback logic so that even resources are declared as required, the check doesn't fail when plugin doesn't provide the resource.
Fix Zotero.File.getResourceAsync to use NetUtil channel to handle jar: url with `@`.
In a newly created profile, we check whether another profile is using
the default data directory, and if so, we create a new data directory
named after the profile (e.g., "Zotero Work"). But on Windows, paths in
prefs.js are stored with escaped backslaches (C:\\Users\\foo\\Zotero),
so searching for the JS string with literal single backslashes
(C:\Users\foo\Zotero) always failed, we would conclude that the default
dir was unused, and we would reuse the existing database.
To fix, escape backslashes in dataDir before the substring check.
Mac/Linux paths have no backslashes so this is a no-op there.
The new-install branch in DataDirectory.init() read prefs.js from the
default Firefox profile to detect a pre-2017 dataDir setting, and the
read was unwrapped, making prefs.js access errors fatal at startup [1].
We could add a try/catch, but after nine years, it's probably safe to
just remove the migration. If anyone is returning from >9 years in the
wilderness and they still want old unsynced Zotero data, they can
manually move their data to the default location.
[1] https://forums.zotero.org/discussion/131176/installation-error-accessing-mozillas-pref-js-see-msg-pls
Columns now have properties: `enabledIn`, `disabledIn` and `defaultIn`,
corresponding to column picker availability and default visibility. The
properties now filter based on attached collection view type instead of
visibilityGroup.
Visibility groups are for views where we want distinct column sets to
persist, like the feeds view.
Collection type properties are used to specify which columns are
available for a given type, regardless of whether it's in a different
visibility group or not.
