ConcurrentCaller wasn't waiting properly if start() was called again
while it was pausing, so 429 caused an immediate retry, which is pretty
much exactly what you don't want a 429 to do.
If a translator couldn't be parsed, `_translatorInfo` wouldn't be set,
and that would somehow cause the translator info for subsequent
detections to be out of sync with the code loading, and nothing would
work. Putting a try/catch around the eval() allows subsequent
translators to continue to work normally. (There might be a better fix,
but this seems to work.)
This was happening for Better BibTeX translators that were still
installed without the extension (which they need to be parsed properly),
causing all imports to break.
https://forums.zotero.org/discussion/86613/error-id-1093166052-upload-of-ris-and-bibtex-data-failed
- 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
After a local item change, Zotero uploads the JSON and then applies the
saved JSON returned from the API to the local object using `fromJSON()`,
the same as it would apply any other remote change.
`fromJSON()` is meant to migrate Extra lines into real types and fields
after future item type/field changes. It calls
`Z.Utilities.Internal.extractExtraFields()`, which looks for valid item
type or CSL type values in Type lines in Extra, handles the rest of
parsing accordingly, and passes back the parsed item type. `fromJSON()`
wasn't handling `itemType` in the response object, so the item type
didn't get applied and the Type line was stripped. This fixes that.
Since valid type values are now parsed, if you have a Journal Article
item with a Pages field and enter "Type: song" into Extra and sync, the
item will be converted to Audio Recording and `Pages: 123` will be
placed in Extra.
https://forums.zotero.org/discussion/comment/369221/#Comment_369221
Creating missing tables breaks schema update steps that assume those
tables don't exist, so we'll need another solution here. For now,
disable the automatic integrity check and make a couple recent schema
update steps more forgiving for people on the beta who already triggered
this.
If there was an existing ~/Zotero directory, another profile was already
pointing to it, and there was a Firefox profile pointing to a custom
data directory or with an embedded 'zotero' directory, the Firefox data
directory would be used instead of creating a new data directory named
after the new profile.
This skips the Firefox logic for new profiles when there's an existing
profile pointing at ~/Zotero and just creates the new data directory.
- Create userdata tables and indexes that are missing
- Delete tables and triggers that should no longer exist
- Run schema integrity check before user data migration
- Run schema integrity check after restart error
This is meant to address two problems:
1) Database damage, and subsequent use of the DB Repair Tool, that
results in missing tables
2) A small number of cases of schema update steps somehow not being
reflected in users' databases despite their having updated userdata
numbers, which are set within the same transaction. Until we figure
out how that's happening, we should start adding conditional versions
of schema update steps to the integrity check.
This is currently only running the update check after a restart error,
which might not occur for all missed schema update steps, so we might
want other triggers for calling setIntegrityCheckRequired().
- Using `sandboxPrototype` properly uses window as prototype
- This commit removes the need for our patch in babel-worker.js:
3d0bc4cf9f
- We properly inject into frames in the client if we ever include frames
4bc8fab4f5 added support for `proxy: false` on attachment URLs in
translators, but it made that flag skip `resolveURL()` altogether, which
meant that relative URLs weren't resolved, rather than just skipping
proxying.
This may fix PDF downloads for some ScienceDirect pages (though I can't
test this one):
https://forums.zotero.org/discussion/85884/problem-downloading-pdf-via-zotero
4be877ca1e
breaks some things in our hidden browser. They can probably all be fixed
by adding `window.` (e.g., `setTimeout()` → `window.setTimeout()`), but
for now just use the commit before that one.
Our SingleFileZ integration would save images inside directories following the
SingleFileZ format. However, Zotero does not support syncing sub-directories of
attachments. This commit switch back to a single HTML file with base64 encoded
resources. We think that the 33% increase in resources will be offset by the
compression of HTML and removal of JavaScript and unused CSS.
This commit does not fix past snapshots that were saved using SingleFileZ.
