This reverts commit 60befe52e4 and adds a
better fix that leaves the notifier event in place. Feeds just don't
need to update after syncs during tests.
It would be good for people not to kill the process indiscriminately, but the
migration will theoretically pick up where it left off, so it shouldn't be too
big a deal.
An endpoint can now take a single object containing 'method', 'pathname',
'query', 'headers', and 'data' and return an integer, an array containing
[statusCode, contentType, body], or a promise for either. This allows the
handlers to use the HTTP method and headers and removes the need for callbacks
when some handlers already use coroutine().
If init() returns a promise, it now has to use the new single-parameter
signature (because the check is done with Function.length, and combining
promises and callbacks doesn't make sense anyway).
This also makes a few changes to `callMethod`:
- Removes the deprecation warning when a string is passed and removes the
`httpMethod` `options` property. Any call that passes a string and includes
`data` can just remain as a POST. If `data` is null or undefined, a `GET`
will be sent. (If we find ourselves needing other methods, we can reevaluate.)
- Renames `httpHeaders` to `headers` for consistency with other code (and in the
absence of `httpMethod`)
Instead, just always show the (greatly shortened, after 0609b62a) menu
on export when the translator supports it (which probably fewer
translators actually need to do).
This leaves the pref in place, but it can be removed eventually (and
changing the default for a while I believe will cause the existing pref
line to be removed for anyone who has it set to true already).
See https://forums.zotero.org/discussion/comment/263644/#Comment_263644
We might want to consider removing the export charset checkbox in the
prefs and either always showing the charset option for translators or
always showing it for BibTeX (where "Western" really means "ASCII") but
nothing else.
Fixes#1124
The Zotero.DataDirectory equivalents return string paths instead of nsIFile
instances, so some of these calls now just use Zotero.File.pathToFile(), which
can be removed when the surrounding code is updated to OS.File,
Look for other profiles, from both apps (Firefox and Standalone), that
point to the data directory being migrated and update prefs.js in those
profiles to point to the new location.
Also reorganize code into Zotero.Profile and Zotero.DataDirectory
namespaces
This prevents us from moving the data directory if the other app
(Firefox or Standalone) is running from the same directory.
Also clean up stub code in migration tests
When an export translator is selected for Quick Copy, Quick Copy
initialization triggers translator initialization a few seconds after
startup, because the translator code needs to be available synchronously
for drag/drop. A Quick Copy test was changing the setting to BibTeX,
which was resulting in random timeouts after subsequent resetDB() calls
due to slow translator loading. This change skips initialization in test
mode. This might actually fix a lot of timeouts on Travis in the second
half of the tests...
This also resets the Quick Copy pref in those tests so that it's left at
the default, though really we should automatically reset all prefs after
all test groups and in resetDB().
Would be nice to have a determinate progress meter on Windows, but that
will require enumerating all files, which maybe would just make things
slower. Might be safer, though, by discouraging people from
force-quitting.
If showZoteroPaneProgressMeter() is called with the first argument
undefined, don't clear any existing message. To clear, pass
null/false/"". The message is also cleared when the progress meter is
hidden.
- Fix#1121, sorting of hasAttachments column -- doesn't work if
hasAttachments is the active sort column on startup, since file states
have to be cached, but works for subsequent clicks on the column
- Don't sort linked URL attachments as missing
- Use hiDPI icon in all cases
This adds a new button to the Advanced prefs to migrate the data directory to
$HOME/Zotero. The button only appears if the data directory is set to the
default location within a profile directory (including the other program from
the one running, even though that's technically stored as a custom data
directory).
On Mac/Linux, directories within the data directory are moved with /bin/mv. On
Windows, or if that fails, they're copied recursively using OS.File.move()
(which annoyingly doesn't reliably support directory moving). The former should
be instantaneous on most systems (unless the data directory or 'storage' were
on a different filesystem from $HOME).
If the database fails to transfer, migration fails and the data directory
setting remains on the old directory. If the database transfers but other files
fail, the data directory setting is updated. In both cases, the user is
encouraged to migrate remaining files manually with a button that reveals the
directories and quits the program.
This isn't yet tested on Linux or Windows, and migration isn't yet suggested
automatically.
Adds Zotero.File.reveal(), Zotero.File.directoryIsEmpty(), and
Zotero.File.moveDirectory().
.persistentDescriptor now appears to return (and parse) a string path anyway on
macOS, which is the only place where it didn't use a string path to begin with,
so this will only affect earlier users.
- Use $HOME/Zotero if zotero.sqlite exists, and set it as a custom data
directory so that 4.0 uses it if loaded (resulting in a
newer-db-version error instead of an empty database)
- Don't prompt whether to use data directory from the other version's
profile directory (i.e., Firefox or Standalone) -- just do it
- Show toolbar icon on startup error (fixes#742)
- Don't show DB upgrade error message for other startup errors
- Fix some cases of a startup error not being logged/presented
- Show actual error in error dialog for more errors
