A browser window was no longer actually needed for charset detection
(on macOS, at least, and hopefully elsewhere) because we switched to a
HiddenFrame-based hidden browser. Remaining uses now call
`loadZoteroWindow()`.
After navigating to the collection from "Libraries and Collections"
section of an item in the trash. Deleted item does not appear in actual
collections and trying to select it will just re-select the trash.
Fixes: #5060
Define missing cancel method on io object passed from the
editor instance to quickFormat dialog. Without this
Escape keypresses throws an error because io.cancel is
undefined.
Followup to #4859
Asks the user if they want to discard the changes in their existing dialog if
they have made changes.
If there is no citation dialog, but a command is running (like updating the document)
an alert is displayed.
Closes#4855
I don't know if something changed in my Ubuntu installation or in the
Firefox runtime (probably the former), but that code crashes Zotero on
wayland.
Window activation (e.g. citation window) does not seem to be affected.
* Display the progress bar on macOS integration commands more
Avoid displaying before Add/Edit Citations, Add Note and Doc Prefs
since that brings Zotero window to the foreground along with the
relevant dialog, but display the progress bar after confirming those
dialogs, which will bring Zotero to the front, but is still better than
no progress indication.
Display the progress bar for Refresh, Doc Prefs, Unlink and Add/Edit
Bibliography
* Fix progress bar indeterminate state not being visible and not working.
- Update _progressMeter.scss for fx115+
- Some adjustments/resizing to progress bar display in quick format
`firstInSession` wasn't being properly set, so previously failed data
objects weren't being retried until a manual sync. Local files also
weren't being scanned for changes for three hours, but that's probably
better in the age of DB-stored annotations, so leave that off for now
and address properly in #5025.
After further consideration, doing this in-app makes more sense. This
way, we'd never be able to update the desktop file automatically (e.g.,
to add a new MimeType), and removing the template zotero.desktop file
would break all existing installs using our symlink instructions.
In-app, we can update the existing desktop file on restart after an
upgrade, and we can remove the existing symlink.
This reverts commit 0ac57f8262.
Possible we'll get complaints about no longer being able to open
multiple copies of at least runJS and csledit, and we can reconsider if
so, but reopening the existing window is certainly the intended
behavior.
Reverts a change I made to the PR. Only `since=0` would be valid in the
web API, but local items don't have a version by default, so it has to
be `-1` to match those. This probably isn't a great solution, since tools
targeting the web API would use `0`, but this will fix the test for now.
