Creators shouldn't be extracted if creators of the same type already
exist on the item, to follow citeproc-js behavior, but the code to do
that was broken.
File renaming has a Notifier handler for item modifications that needs
best-attachment titles, but attachments and their item data might not be
loaded even when parent items are. (This came up when migrating fields
from Extra after a global schema update before the main window had
loaded.)
- Replace polling with a `ready` promise for initialization
- Use fixed height for the rich list and re-order initialization to avoid layout shifting
- Ensure the "accept" button is disabled until initialization completes
Allow one to switch between "Add/Edit Citation" and "Add Note" modes
in the citation dialog via segmented control in the bottom
left corner.
One cannot switch modes when editing an existing citation or
when inserting a citation in the note editor.
Use the same segmented control UI to switch between
list and library modes for clarity. Replace icons with
"List" and "Library" strings.
Collect some of the state variables into DIALOG_STATE object
for better organization.
Fixes: #5582
Also, remove earlier logic of not resizing window on refocus
on Linux if focus was lost <100ms ago. That workaround
no longer works, and now that we retain the window sizing
after search reruns, it is less of an issue.
Addresses: #5590
When fetching open tabs for the citation dialog, fall back
to the last saved session state if the main window is closed.
Session state was already being updated when zotero pane
is closed.
Fixes: #5661
When a Zotero plugin is disabled, user-modified preferences can be inadvertently reset to their default values. This occurs under specific conditions where a parent preference has not been user-modified, but a child preference within that branch *has* been modified.
The root cause lies in the `Zotero.Plugins.clearDefaultPrefs` function. For preferences that do not have a user-set value (`!branch.prefHasUserValue(pref)`), it incorrectly calls `Services.prefs.getDefaultBranch('').deleteBranch(pref)`. While intended to clear unmodified defaults, `deleteBranch(pref)` operates on the *entire preference branch* starting with `pref`, inadvertently removing any user-modified sub-preferences as well.
This commit changes the problematic line from `branch.deleteBranch(pref)` to `branch.clearUserPref(pref)`. `clearUserPref(pref)` correctly removes only the user-set value for the *specific* preference `pref`, leaving default values and any user-modified sub-preferences intact. This ensures that only truly unmodified default preferences are cleared, preserving user data for related sub-preferences.
This fix prevents unintended loss of user settings when plugins are disabled.
