.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
This could be extended to address #118/#145, but for now it makes some of the
more common search conditions (Creator, Collection, etc.) more prominent.
With icons to identify collections and searches
Also:
- `savedSearch` search condition in general
- Clean up some search window code
- Reorganize search tests
Calling getTransferData('zotero/item') when handling the
application/x-moz-file-promise seems to have stopped working between Fx46 and
Fx47, though I can't get older Nightly builds to run with mozregression
(Sierra?) to find the specific change. Instead, work around this by passing an
array of item ids to the file drag data provider.
Using createDocumentFragment() and event delegation
Filtering for a tag could still be sped up quite a lot. Resizing the tag
selector is also very laggy, but that might require switching to clusterize.js
or similar.
This is the recommended approach (since NetUtil can still do some main-thread
I/O for files) and avoids warnings in the console.
For getContentsAsync(), also sends nsIURIs and string URIs to
Zotero.HTTP.request(), which should be used instead.
This makes getBinaryContentsAsync() much slower (due to the conversion from an
array of bytes to a binary string), but it's only used in tests. For one test
that compares two large files, use MD5 instead.
Clicking it cancels the current window, opens the Cite pane of the
prefs, and selects the Styles tab. (This will be more useful once we
have inline style installation from that pane.)
- Move openPreferences() to Zotero.Utilities.Internal
- Add support for opening windows when there's no active browser window
- Allow selecting prefpane tab by id via 'tab' property
- openPreferences() now takes an object as its second argument with a
'tab', 'tabIndex', or 'action' property
In translation-server, the test timeout is overridden to 30 seconds, which was
also the deferred test delay, so there was a race condition that could cause
deferred tests to fail. This sets the deferred delay to 20 seconds.
Safari does not support generators yet. Removes coroutines
and removes the requirement for bluebird, which should
improve script injection performance.
For some reason, in the Fx48 translation-server, the processor passed to
processDocuments() calls in translators can't access document properties
even when they're on the same domain or even the same document. To get
around that, rewrap them for the sandbox, but there might be a better
fix here.
Addresses https://github.com/zotero/translation-server/issues/36
A few sites (e.g., Gallica) were causing alerts to pop up in Standalone during
testing, which breaks testing, so accept them automatically. (Hopefully these
don't happen during manual translation...?)
If an object exists locally but not remotely and the local version has a
version number, that's an error. I don't think that should ever happen,
but it can if things somehow get out of sync due to other bugs.
To address, reprocess the API delete log during a full sync and then
reset the version number of all remaining local objects that don't exist
remotely (not just unmodified objects, as was the case previously) to 0
for uploading.
When remote deletions are reprocessed, delete local objects that haven't
been modified and show the conflict resolution window for any local
items that have.
Also:
- Clean up checking of last remote library version during download
syncs
- Add Zotero.DataObjects.getAllKeys()
The client skips synced storage properties (md5, mtime) when uploading items to
ZFS-enabled libraries, but since the API returns JSON with those values
included after writes, they do get saved to the sync cache. If the local
attachment is then modified and the client generates a diff from the cached
version with those properties skipped, they'll be included in the patch JSON as
empty strings in order to clear them. This changes Zotero.Item::toJSON() to
skip those properties in patch mode as well.
This fixes a sync error ("Cannot change 'md5' directly in group library") when
a group attachment is updated locally.
Reapplies modifications to SpecialPowers code after a0843f317
This is essentially the changes within the SpecialPowers code block from this
diff, with some modifications for the new code:
git diff 1257b17e..a0571a9a17 chrome/content/zotero/xpcom/translation/translate_firefox.js
This fixes the "Proxy.create is not a function" errors during PDF
metadata retrieval in Firefox 48 after the old Proxy API removal, but it
still throws "doc.location is null".
Addresses #1076
This shouldn't happen, but if it does, the API should return a 412 for
such objects, resulting in a full sync. Until the API fix is rolled out,
do the same on a 404.
If the item was deleted on one side and moved to the trash on the other,
just delete the item on the trash side. Since trash emptying happens
automatically, this would otherwise result in a conflict even if the
user carefully avoided making changes before a manual sync.
There's no need for Zotero Standalone add-ons to be signed by Mozilla.
Currently only hides when the Extensions pane is first loaded, so if the user
switches to Appearance or Plugins and switches back, the warning reappears
On reset, items are overwritten with pristine versions if available and deleted
otherwise, and then the library is marked for a full sync. Unsynced/changed
files are deleted and marked for download.
Closes#1002
Todo:
- Handle API key access change (#953, in part)
- Handle 403 from data/file upload for existing users (#1041)
Set a unique id on the note editor at initialization and pass it along
to item.saveTx(). When notify() is called, if the save was triggered
from the current note field, don't do a refresh.
This does mean that the note field won't reflect changes (e.g.,
normalizations) made by the save process until the user clicks away and
back, which makes me a little uncomfortable. If we can find specific
cases where that occurs (paste?), we can reevaluate this approach.