It would be good for people not to kill the process indiscriminately, but the
migration will theoretically pick up where it left off, so it shouldn't be too
big a deal.
An endpoint can now take a single object containing 'method', 'pathname',
'query', 'headers', and 'data' and return an integer, an array containing
[statusCode, contentType, body], or a promise for either. This allows the
handlers to use the HTTP method and headers and removes the need for callbacks
when some handlers already use coroutine().
If init() returns a promise, it now has to use the new single-parameter
signature (because the check is done with Function.length, and combining
promises and callbacks doesn't make sense anyway).
This also makes a few changes to `callMethod`:
- Removes the deprecation warning when a string is passed and removes the
`httpMethod` `options` property. Any call that passes a string and includes
`data` can just remain as a POST. If `data` is null or undefined, a `GET`
will be sent. (If we find ourselves needing other methods, we can reevaluate.)
- Renames `httpHeaders` to `headers` for consistency with other code (and in the
absence of `httpMethod`)
If someone can manage to reproduce this locally, we can try a real fix:
✖ [FAIL] should show tags in alphabetical order
AssertionError: expected '' to equal 'A, B, C' at
@resource://zotero-unit-tests/noteeditorTest.js:61:4
Instead, just always show the (greatly shortened, after 0609b62a) menu
on export when the translator supports it (which probably fewer
translators actually need to do).
This leaves the pref in place, but it can be removed eventually (and
changing the default for a while I believe will cause the existing pref
line to be removed for anyone who has it set to true already).
See https://forums.zotero.org/discussion/comment/263644/#Comment_263644
We might want to consider removing the export charset checkbox in the
prefs and either always showing the charset option for translators or
always showing it for BibTeX (where "Western" really means "ASCII") but
nothing else.
Fixes#1124
The Zotero.DataDirectory equivalents return string paths instead of nsIFile
instances, so some of these calls now just use Zotero.File.pathToFile(), which
can be removed when the surrounding code is updated to OS.File,
Look for other profiles, from both apps (Firefox and Standalone), that
point to the data directory being migrated and update prefs.js in those
profiles to point to the new location.
Also reorganize code into Zotero.Profile and Zotero.DataDirectory
namespaces
This prevents us from moving the data directory if the other app
(Firefox or Standalone) is running from the same directory.
Also clean up stub code in migration tests
