Instead of requiring a click on the menuitem at the top of the submenu, allow
a click on the menu itself.
This is a hack that, among other things, replicates the flash effect on
menuitems on OS X. Unfortunately, <menu> elements can't have checkboxes, so
only the menuitem in the submenu will be checked. (Otherwise I'd remove the
redundant menuitem in the submenu.)
- Allow clicking on non-editable abstract field to expand/collapse it
- Change cursor when hovering over abstract to show it can be toggled
- Default abstracts to expanded
- Fix persistence of last translation target
- Add checkbox to menuitem of selected target
- Remove unnecessary flex attributes
Also:
- Move collectionTreeView row id (e.g., "L1", "C123") and image
generation to Zotero.Library and Zotero.Collection properaties,
.collectionTreeViewID and .collectionTreeViewImage -- currently used
only for the feed add-to button, but could be expanded for use in
collectionTreeView
And without extra init() call
This fixes the button being initialized before Zotero.hiDPI is set, resulting
in a low-res icon until the target is changed.
The on-change auto-sync now syncs only the modified library, and does so
quite efficiently (and should be able to be made more efficient), so we
might be able to reduce the timeout below 15 seconds.
Instead of getting batches of unused primary key ids, even if they're lower
than other ids, which for some reason seemed like a good idea in 2008, just do
a `MAX()` on the table at startup and return the next available id on each call
to `Zotero.ID.get()`. This is much simpler, and not reusing ids allows them to
be used as a chronological sort field.
While SQLite's `SELECT last_insert_rowid()` could return auto-increment values,
it's unsafe with async DB access, since a second `INSERT` can come in before
the first `last_insert_rowid()` is called. This is true even in a transaction
unless a function that calls it is never called in parallel (e.g., with
`Zotero.Promise.all()`, which can be faster than sequential `yield`s).
Note that the next id is always initialized as MAX() + 1, so if an object is
added and then deleted, after a restart the same id will be given. (This is
equivalent to (though unrelated to) SQLite's `INTEGER PRIMARY KEY` behavior,
as opposed to its `INTEGER PRIMARY KEY AUTOINCREMENT` behavior.)
Closes#993, Feed items out of order
Previously, objects were first downloaded and saved to the sync cache,
which was then processed separately to create/update local objects. This
meant that a server bug could result in invalid data in the sync cache
that would never be processed. Now, objects are saved as they're
downloaded and only added to the sync cache after being successfully
saved. The keys of objects that fail are added to a queue, and those
objects are refetched and retried on a backoff schedule or when a new
client version is installed (in case of a client bug or a client with
outdated data model support).
An alternative would be to save to the sync cache first and evict
objects that fail and add them to the queue, but that requires more
complicated logic, and it probably makes more sense just to buffer a few
downloads ahead so that processing is never waiting for downloads to
finish.
