When refreshing the note editor, store the associated itemID on the
textbox, and check it when saving to make sure it's for the expected
note. This might prevent weird situations (which I can't reproduce, but
there was a report in the forums [1]) where something goes wrong and the
note doesn't refresh when selecting a new item, and then one note's
content is saved over another's.
[1] https://forums.zotero.org/discussion/65708/
While objects in the sync queue that fail to save should remain in the
queue, objects that just don't exist remotely need to be removed, or
else they'll be retried forever.
This makes it a little easier to use the proper plural form of a word.
Currently this only supports English forms and is used only in debug
output. For proper plural form support, use PluralForm.jsm.
There was a report [1] of slow file syncing that showed all file
timestamps being reported as ending with 020 (e.g., 1436492361020). The
previous code assumed that systems without millisecond precision would
report as whole seconds, so the timestamp checks weren't matching and it
was moving on to hash-based checks (which seemed to be taking a very
long time, but that's another matter). This changes the comparison so
that, as long as both timestamps floor to the same whole second, they'll
be considered equal.
[1] https://forums.zotero.org/discussion/65515/5-0-beta-sync-problem
Item data may not have been loaded for a library when requesting an item
from a document (e.g., for Refresh), so we need to load all data for
requested items to avoid unloaded-data errors. (Data isn't loaded if
it's already been loaded, so hopefully this doesn't slow things down too
much.)
d5cf33a798 adds a `yield` to bibliography.js, which runs in modal
windows (e.g., Create Bib), but there's a weird interaction between
Bluebird and modal dialogs that can result in hangs -- presumably
something to do with things being queued on the event loop but the modal
dialog preventing other code from running? This was breaking
bibliographyTest, but it seemed to work fine for me in normal usage,
waiting properly for a running styles initialization to finish. It's
possible this problem is limited to tests, but in the past, at least, I
apparently decided that this was a general problem with `yield` in modal
dialogs [1]. (See also: [2].) In any case, calling `yield
Zotero.Styles.init()` from the Create Bib window was hanging the test,
so for now do a synchronous check for style initialization to avoid it,
and we should make sure that `yield` actually works in other contexts.
[1] https://github.com/zotero/zotero/commit/99dd1c069776
[2] https://github.com/zotero/zotero/commit/c2dd531cec4
Instead of My Publications being a separate library, have it be a
special collection inside My Library. Top-level items can be dragged
into it as before, and child items can be toggled off and on with a
button in the item pane. Newly added child items won't be shown by
default.
For upgraders, items in the My Publications library will be moved into
My Library, which might result in their being duplicated if the items
weren't removed from My Library. The client will then upload those new
items into My Library.
The API endpoint will continue to show items in the separate My
Publications library until My Publications items are added to My
Library, so the profile page will continue to show them.
Contains a dummy doc plugin, which is useful for:
- Testing integration.js functionality
- Serving as succint documentation for development of new integration
plugins
I don't know why why, but wbp.saveDocument() destroys the
document object which is passed into it. This means that further access
of the document is impossible and raises errors, which we were not
handling properly and not returning on attachment saving.
I've added error handling and changed removed code which tries to access
the document after the Zotero.Utilities.Internal.saveDocument() call.
Addresses https://forums.zotero.org/discussion/64745/5-0-beta-apparently-stuck-at-saving-to
The web library will probably still display the old tag in addition to
the new one, at least until browser restart. We'll have to deal with
that separately.
Closes#1205
When refreshing, if fewer than 100 tags to show, just create them from
scratch instead of updating the full set. Otherwise, remove the full set
from DOM and add it back in after updates to avoid reflows (from #1204).
There are various things that could be done to optimize this further
(avoiding unnecessary sorting during full refreshes, calculating a hash
of the full set and not updating it every time), but we should probably
just replace it with @tnajdek's React version first.
Closes#1204
Changes `libraryTreeView::addEventListener('load')` and similar to
`libraryTreeView::onLoad.addListener(listener, once)`, etc. `once` is an
optional boolean that, when true, causes the listener to fire once and
then be removed. This is implicit for 'load'.
'load' maintains its special behavior of running immediately if the
treeview has already been loaded.
Also adds `waitForLoad()` and `waitForSelect()` functions that return
promises on event completion, since most uses of those events were just
resolving deferreds.
TODO: Add text fields for controlling number of items and chunk size
(Chunk size should be small for testing UI interactions and performance
but large for generating lots of data.)
For building up a big library and testing UI interaction during writes
To use, load chrome://zotero/content/tools/data_generator.html in
Firefox (for now).
Could be improved a bit to add other kinds of data (collections,
child items, relations)
The items list is generated from the database (via search), but new
items may have been added to the database but not yet been registered,
causing unloaded-data errors during sorting. Avoid that by not showing
unregistered items when generating the items list.
Additional protections are necessary -- it's still possible to get
errors, and maybe a crash, if an item has been registered but not yet
fully loaded -- but this addresses the most common one.
We could monkey-patch a finally function in connectors as described in
this gist https://gist.github.com/jish/e9bcd75e391a2b21206b , but it
appears to silence propogation of unhandled rejections
and it could later come back to bite us in the butt.
Native and proper support for finally is, however, planned in ES7.
When dragging an item to another library, we have to check if there's a
linked item in the target library, but items might not yet be laoded in
the other library, so item.getLinkedItem() can fail with "Item [n] not
yet loaded].
Fixing required asyncifying the follow functions:
- Zotero.Item::getLinkedItem()
- Zotero.Collection::getLinkedCollection()
- Zotero.URI.getURIItem()
- Zotero.URI.getURICollection()
- Various integration functions
As noted in 27cb099c82, import translators should be rewritten to return
a promise from doImport() and wait for promises from successive
item.complete() calls. They should then be marked as minVersion: "5.0"
to be handled properly by this new code.
(But this tries to account, albeit with somewhat worse behavior, for
translators that haven't been rewritten and sandboxes without Promise
(which is currently the case with child sandboxes in the client).)
(Oh, and I haven't tested this at all in the connectors.)
Function that automatically follows Link headers and makes additional
requests as necessary, feeding the XMLHTTPRequest object from each
request to a reducer function.
- Archive remotely missing that user chooses to keep
- Ignore archived groups that don't existing remotely
- Unarchive groups that become available again
This can happen because objects are uploaded in batches, but the version
number from the last batch is used for all objects (since
APIClient.uploadObjects() handles batching internally).
Previously on Windows, where we don't have /bin/mv, we were recursing
into the data directory and copying files individually, which is very
slow, so automatic migration was disabled. Instead, try moving
directories with OS.File.move() with the `noCopy` flag. Moving
directories is technically unsupported by OS.File, but probably only
because of the possibility of a cross-volume copy (which is only
implemented for some platforms), and using `noCopy` hopefully prevents
that. If someone does have their data directory or storage directory on
a different volume, the migration might be quite slow, but leaving a
data directory behind in the Firefox profile directory (where it can be
easily misplaced with a seemingly unrelated Firefox reset) is worse.
