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.
After 015769a removed pointer-events: none from table cells,
clicking on the collectionTree would always trigger
a focusout event, ZoteroPane.handleBlur would call
collectionTree.setHighlightedRows, which would always
redraw the collectionTree. This complete tree redraw on
every click made it impossible to register double-clicks.
With this change, setHighlightedRows won't have
any effect if called with the same rows to highlight
as before (including no rows).
Without constant tree redraws, double-clicks fire as expected.
Fixes: #5655
Fix new collection dialog appearing broken when
opened via "New Collection" option of context menu
on "My Library" or a group in collection tree.
On macOS, the popup of collections would never leave
and on windows, subcollection would never appear.
This is a followup to zotero#5409
that fixes this issue for all collections. The reason
why it didn't work for groups is that the command event
would fire not on a menuitem but on the <command> node itself,
which is not what the workaround expects.
Now, if we get such an event, we'll try to use the
original 'command' event dispatched on the <menuitem>
from event.sourceEvent to locate the <menupopup>
and as a blueprint for redispatching the event.
Fix createParentDialog hanging when opened during
quicksearch or in saved search. After a parent item
is added, itemTree is being refreshed. If _refreshPromise
is resolved after a timeout, it will not complete until the
modal dialog is closed. Instead, resolve _refreshPromise
after Zotero.Promise.delay, which uses the XPCOM global
timer unaffected by modals.
Fixes: #3026
Another potential fix to the test failure. Earlier fix
from 30784dd241 seems
to not have worked.
A new explanation is that the test before it does not properly
wait for the trash to refresh before trying to select the library, in
which case collectionTree select event will be suppressed
and library selection will not happen.
Fixes: #5584
This test would sometimes fail, most likely due to
the library sometimes not getting re-selected in the previous test
'should update custom header for items in the trash'.
A likely explanation is that the selection event in
collectionTree would still be suppressed when selectLibrary
is called, so make sure to wait for item deletion to
go through before trying to re-select the library.
Fixes: #5584
