This reverts Zotero.Translate.ItemGetter.prototype.nextItem() to being
synchronous post-deasyncification. This will need to be made to work
asynchronously in the future if _attachmentToArray(), which is called by
nextItem, is changed to use async file access (which might be required
at some point).
Addresses #734, [Async DB] Import/export fails
notificationCallbacks no longer QIs to webNavigation in Firefox 46, so
this gets the relevant browser object by getting the content window id
from channel.loadInfo and finding the window via nsIWindowMediator.
Unfortunately the window id provided under e10s is invalid (or something
-- it's a very high number that can't be found via nsIWindowMediator),
so something else will need to be done for that.
This allows Zotero.Relations.getByPredicateAndObject()/getByObject() and
Zotero.Item::getLinkedItem()/Zotero.Collection::getLinkedCollection() to
be synchronous, which is necessary for word processor integration.
Instead of creating a duplicate copy of the item with the same primary
data and saving that, it's safer just to use clone() (which doesn't
preserve ids) and apply changes to the main object.
While trying to get translation and citing working with asynchronously
generated data, we realized that drag-and-drop support was going to
be...problematic. Firefox only supports synchronous methods for
providing drag data (unlike, it seems, the DataTransferItem interface
supported by Chrome), which means that we'd need to preload all relevant
data on item selection (bounded by export.quickCopy.dragLimit) and keep
the translate/cite methods synchronous (or maintain two separate
versions).
What we're trying instead is doing what I said in #518 we weren't going
to do: loading most object data on startup and leaving many more
functions synchronous. Essentially, this takes the various load*()
methods described in #518, moves them to startup, and makes them operate
on entire libraries rather than individual objects.
The obvious downside here (other than undoing much of the work of the
last many months) is that it increases startup time, potentially quite a
lot for larger libraries. On my laptop, with a 3,000-item library, this
adds about 3 seconds to startup time. I haven't yet tested with larger
libraries. But I'm hoping that we can optimize this further to reduce
that delay. Among other things, this is loading data for all libraries,
when it should be able to load data only for the library being viewed.
But this is also fundamentally just doing some SELECT queries and
storing the results, so it really shouldn't need to be that slow (though
performance may be bounded a bit here by XPCOM overhead).
If we can make this fast enough, it means that third-party plugins
should be able to remain much closer to their current designs. (Some
things, including saving, will still need to be made asynchronous.)
If 'pdf' flag is included in object POSTed to saveSnapshot, import the
PDF directly and save as top-level item. Currently the PDF is
redownloaded -- there might be a better way to get the PDF data over
without redownloading. (It uses passed cookies, though, so gated PDFs
should still work.)
I guess the idea that switching to PNGs obviated the need for this was wishful
thinking (though it doesn't seem to be necessary for the single buttons anymore
on Linux, and it's no longer necessary on OS X, which has generally saner
styling in Firefox).
- Fix spacing on Windows and Linux in latest Firefox versions
- Tweak icon colors on Windows and OS X
- Adjust Z SVG to take up full height, so Z is a full 16px instead of
14px with slight anti-aliasing
- Use generated PNGs instead of SVG for Z toolbar icons, to remove the
need for complicated size rules
- Add separate platform-specific .svg files that are used by a
zotero-build script, make-z-icons, to generate the Z PNGs; the main
SVG is still used directly in the menu panel and customization
palette, with platform media queries to determine the coloring
Unfortunately this will need to be partly redone, since retrieveItem(), and
therefore itemToCSLJSON(), and therefore itemToExportFormat(), need to be
synchronous. The item data load statements in itemToExportFormat() will
probably need to be performed earlier, when they can be async, and made
available to the session for retrieval by retrieveItem(), but I'll let someone
more familiar with the citation infrastructure do that.
This restores some code in retrieveItem() that may have been accidentally
removed in a merge, though it probably won't be useful anymore anyway.
Addresses #529
Now that 500 errors are retried in file downloads (ec28c5a3), we have to
override the default backoff schedule in order to get expected failures.
This also fixes an error that occurred on a retried download.
In Fx44, SQL queries must use '?' with LIKE and cannot concatenate a
placeholder string (e.g., 'foo%'). This is for Sqlite.jsm only, so it
doesn't affect 4.0.
