Well this was a wild one to debug.
Creator fields were only initialized for autocomplete due to a series of
>10-year-old bugs:
1) In `showEditor()`, `Zotero.ItemFields.isAutocompleteField(fieldName)`
was called for creator fields, which would pass, e.g.,
`creator-0-lastName`.
2) In `isAutocompleteField()`, `ItemFields.getName()` would normalize
`creator-0-lastName` to `false`, since it's not a valid field.
3) `isAutocompleteField()` listed `place` as a base field despite its
not having any mapped fields, so when `getTypeFieldsFromBase()` was
called on it, the return value would be `false`, which would be added
to the list of autocomplete fields, which would mean that the
normalized field of `false` from `creator-0-lastName` would match,
which would mean that `isAutocompleteField('creator-0-lastName')`
would always return true...as long as `place` never gained a mapped
field.
Except `isAutocompleteField()` wasn't supposed to be the test for
initializing autocomplete for creator fields anyway -- `fieldName ==
'creator'` was. But `fieldName` is something like `creator-0-lastName`,
not `creator`, which meant that that test always failed, which meant
that if `place` did gain a mapped field, both tests would fail, which
would cause the creator field not to be initialized for autocomplete,
which would cause it to break as soon as you started to type into it.
This fixes that.
Panes were being loaded with Zotero_Preferences as their global scope, so global
variables they defined would be set on that object instead of the window.
The file should follow the same `pref("extensions.foo.bar", "value");`
syntax as files previously in defaults/preferences/, which should no
longer be used in Zotero 7. (For an extension that works in both Zotero
6 and 7, it's OK to have a file in defaults/preferences for Zotero 6 and
an identical prefs.js for Zotero 7.)
Files in defaults/preferences/ aren't automatically loaded when a plugin
is installed/enabled but are still loaded at app startup by Mozilla code
for now. Plugins shouldn't count on that continuing to be the case in
Zotero 7 and should switch to prefs.js.
We'll add a way for bootstrapped plugins to manually trigger reading of
a prefs.js file in Zotero 6.
Using the Headers class from the Fetch API.
Before, the added test would fail: `_requestInternal()`, not finding a header
named `Content-Type` (case sensitive), would set it to
`application/x-www-form-urlencoded`. XMLHttpRequest, upon being given both
`content-type`: `application/json`) and `Content-Type`:
`application/x-www-form-urlencoded`, would helpfully merge the two, producing
`content-type`: `application/json, application/x-www-form-urlencoded`. That's
obviously not the correct behavior.
Limited to a hard-coded list
Initially limited to `extensions.zotero.import.mendeleyUseOAuth`,
to switch the Mendeley importer from direct login to OAuth
Services.locale always wants an array now, but it can be empty.
We still get "Uncaught (in promise) undefined" printed to the console, no stack,
not caught by "Pause on exceptions" in the debugger... but it's not clear that
that's actually coming from this code, and it doesn't seem to prevent anything
from working.
