Fix ghost relations to erased items reappearing after
sync. The dataserver ensures that related relations are
bidirectional. If a related item is erased, syncing
would first upload the update to the remaining related item
(where the relation is removed), followed by the deletions.
While handling update upload, the dataserver would return
the old, should-be-removed, "dc:relation" entry for that item
because it does not know that the other item is erased.
To handle this, swap the order of operations during sync:
upload deletion first and then upload updates after.
Then, when the dataserver handles the update of the non-erased item,
there is no related item to enforce bidirectional relations to.
Fixes: #5481
- close hyphenationTest window.
- properly close zoteroPane window in preferences_syncTest.
after() hook inside of the test would not close the window until the
very end of the entire test run. Without this, during
subsequent tests that open their own zoteroPane window, there
are two instances of zoteroPane open at the same time.
- close open tabs in readerTest cleanup, since subsequent
tests expect library tab to be selected.
Followup to https://github.com/zotero/zotero/pull/5444#issuecomment-3141879892
As the comment says, this hasn't been useful (and isn't used anywhere),
and I honestly don't understand how the test ever passed - process()
would've resolved all the feed item promises already.
Fixes#5412
A test using `assert.eventually` was failing after the Bluebird removal
but worked with just `await`, and since there hasn't really been much
point to Chai as Promised since the introduction of `async`/`await` ages
ago, just remove the library instead of figuring out why.
OK, the timeout removed in 05e8da wasn't actually useless, but this test
was.
41706a changed erase() so it no longer forwards skipNotifier when
deleting child items. That means that we *would* get a notify() call for
the deleted child, so the test should have been failing.
However! Because of a bug in Bluebird's filtered catch() implementation,
Promise.TimeoutError wasn't recognized as an Error subclass, and it was
instead used as a predicate function, which would always pass.
So all errors were caught as "timeouts" and suppressed, making this test
always pass. Now it no longer always passes (but does pass with the
current behavior).
This is really messy and not ideal, but these tests were written for
Bluebird Promise state inspection, and it's difficult to make them look
nice without that being available.
`fetch_xulrunner`, `dir_build`, and `build.sh` now take an optional `-a`
argument on Windows and Linux to specify the architecture to
fetch/build. If `-a` is omitted for `dir_build` (as in `build_and_run`),
it defaults to the current architecture.
xulrunner hashes are now computed for each architecture. This changes
some filenames in xulrunner/, so you may want to clean out some old
folders/files.
This removes the custom handling for CI, since it will now default to
the architecture of the test runner.
All module code runs in strict mode, and that breaks Bluebird.
And add a partial shim for the simplest and most useful methods. Not
sure if we actually want that, or if we should just replace it entirely
with native methods.
This was a regression from the switch to `Zotero.HTTP.download()`. 302
wasn't a success code, so `HTTP.download()` would throw, and since the
status wasn't set correctly on the `XMLHttpRequest` within
`HTTP.UnexpectedStatusException`, it would think it was an interrupted
S3 connection and trigger another download after a delay.
* Fixed an issue where the window size did not match the content
* Replaced the semi-transparent progress bar with a spinner
* Fixed a problem that allowed triggering a search while one was already in progress
* Reduced code complexity
