- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
bb220ad0f2...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
- Use cookies from browser pane when running detectWeb or doWeb
- Use cookies from document when running or updating tests
This should fix various cases where translators can't be properly
developed or tested in Scaffold (e.g., [1]).
[1] https://github.com/zotero/translators/pull/2296#issuecomment-739116620
This seems like it would be sufficient for most tests that need to wait
for a page to load and is much less annoying in Scaffold. We could
adjust for automated runs if those end up using a browser again.
Previously, while updating a test used loadDocuments() (for a real
browser load) and honored `defer: true`, running a test did not.
This updates Zotero_TranslatorTester to use loadDocuments() when run in
Zotero. In other environments (translation-server, connector), it will
continue to use processDocuments(), which is based on XHR.
Fixeszotero/scaffold#96
`nsIFilePicker::show()` is removed in Firefox 60 in favor of `open()`,
which takes a callback (and apparently has been preferred for a long
time).
There's no point switching to that, so this module is a version of
nsIFilePicker with an async `show()` that returns a promise and some
XPCOM-isms replaced (e.g., string paths instead of nsIFile).
Zotero.Translate::setTranslatorProviderMethods(methods) can be used to
provide custom 'get' and 'getAllForType' methods that override the
default Zotero.Translators methods.
Also:
- Actually use the cookie sandbox passed to processDocuments()
For zotero/translation-server#16, we want to include Accept-Language
(and maybe other headers) from the client request in upstream requests,
which requires passing it to both non-translate processDocuments().
translation-server's non-translate processDocuments() is defined in that
repo, but it's called by the cross-repo translate processDocuments() in
utilities_translate.js, so the signature needs to be changed in both
repos.
We also apparently weren't using the cookieSandbox in client
processDocuments() calls, though I think that only would've affected
translator testing.
This reverts commit e526a8fa89.
This is a repeat of a0ca67d879. The reverted changes break Scaffold.
This will need to be fixed in a way that allows Scaffold to continue to
work.
I didn't look into the details, but `this` isn't defined when this file
is loaded within Scaffold, so this line caused an error and the
translator tester was broken.
processDocuments() now uses an XHR 'document' request, wrapped to
provide a 'location' property, and uses promises for a simpler call
signature (though the old one will continue to work, for existing
translators). 'done' and 'exception' can now be handled via promises,
and in the translator sandbox an optional noCompleteOnError argument
instructs it not to automatically cancel the translation process with an
error (e.g., for supplementary materials).
Since we do need a hidden browser in some situations (e.g., for saving
snapshots), the old hidden-browser-based processDocuments() is still
available as Zotero.HTTP.loadDocuments().
This hopefully also fixes various problems with document property access
in translation-server.
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)
