When drag-dropping items into a collection in another library,
perform the addition to collection in the same transaction
as creating a new item in the target library.
When the librariesCollectionsBox refreshes on the `modify` event
when a newly created group item is linked to the selected item,
it re-loads the data of the linked item via item.loadAllData().
This could happen after the item is added to the collection
but before this change is saved. In that case, item._changed.collections
would be cleared, and when the item is saved, there would be
no changes to collections to save.
Fixes: #5539
Also, cleanup leftover unused logic of restoring linked item
from trash on drop that was removed in 2dd16b44d6
And require checkbox or text challenge depending on the severity of the
action
Includes replacement for Set.prototype.difference() for Fx115
---------
Co-authored-by: Dan Stillman <dstillman@zotero.org>
If a file was renamed remotely and a new copy wasn't uploaded for some
reason, the ZIP wouldn't contain the new filename. We already renamed a
single file within the ZIP to match the new filename, but now we also
rename a single HTML file in old multi-file snapshot ZIPs. If there are
multiple HTML files for some reason (old-style ZIP with iframes?), we
let the user fix it.
And then we can stop reuploading files after renames.
Previously, the local file wasn't renamed, so it would become unlinked.
Since we currently force reuploading/reregistering of files when they're
renamed, opening the attachment would then redownload the modified
remote file, but there's no need for the file to become unlinked in the
first place.
restoreProcessorState() breaks locale-specific punctuation (and is
deprecated).
rebuildProcessorState() is enough if we're passing an empty citation
list; if we're reinitializing with a new non-empty list, call
updateItems() first.
Also:
- Add tests for this issue and for potential regressions in disambiguation handling
Hopefully a better fix for #4981, which wasn't working properly on at
least some Linux systems because the variables were getting restored
before the subprocess launched. This delays a (debounced) second, to
give the subprocess time to start, and then automatically restores the
variables.
An explicit restart via app code also immediately restores the
variables, since restarts on Linux inherent the environment and don't
use our startup script. (An upgrade restart could still happen when the
variables were cleared, but you'd have to be extremely unlucky --
launching URLs or files while also performing a manual restart the same
second.)
I've run into this randomly. It only occurs if the first operation on a
Google Doc since Zotero restart is the edit bibliography dialog which
you cancel. Due to how the HTTP integration client is implemented, the
missing await causes it to try to send another response to the Connector
(which is no longer waiting on the /response endpoint), failing and
causing a forever pending promise, which makes subsequent attempts to
interact with the Google Docs plugin no-op.
We get occassional reports from users about Google Docs getting stuck
that is fixed by Zotero restart, so hopefully this will reduce those.
This was a regression from the switch to `Zotero.HTTP.download()`. 302
wasn't a success code, so `HTTP.download()` would throw, and since the
status wasn't set correctly on the `XMLHttpRequest` within
`HTTP.UnexpectedStatusException`, it would think it was an interrupted
S3 connection and trigger another download after a delay.
