There were a few problems causing the incorrect behavior:
1. Rows were being removed only if they had no non-deleted children, which
wasn't the right check. We want to remove all rows with no *deleted*
children.
2. Children of the removed rows weren't being removed with them.
3. We weren't invalidating the tree (which _removeRows() doesn't do).
Also:
* Erase trashed annotation after getAnnotations() test
Because ItemTree#notify() doesn't yet correctly handle refresh events on
parent items that are themselves children (three-level nesting: item ->
attachment -> annotation), this test was causing a failure in
itemTreeTest.js.
We don't usually want an async detectWeb, since HTTP requests should only be
used there in very exceptional cases. We do usually want an async scrape (and we
were already - mistakenly - awaiting it).
20c6fe6737 caused this to start failing, but only because the test was
testing something too specific. The change in that commit caused more
rows to be left behind when emptying the trash (for reasons I should
probably look into), but the trash wasn't being emptied properly before,
which #2606 should fix. This test should be restored as part of that PR.
Expose annotation tags in tag selector and match parent attachments when
filtering/searching
This also fixes searching for annotation text or comments when using
Everything quick search.
This is temporary until we display annotations in the items list
directly.
hideEditor() called switchCreatorMode() too early, setting the fieldMode
attribute on the soon-to-be-discarded textbox instead of the label
replacing it. Then, showing the editor a second time would carry over an
empty fieldMode attribute from the label to the new textbox. Hiding that
editor would update the creator in the item to fieldMode = 0 and trigger
a save.
Moving the switchCreatorMode() call does the trick, and the flex
settings changes still work fine when made there.
This one's probably been around for a while! Reproduce by creating an
item with a fieldMode = 1 creator, tabbing past the creator, and then
shift-tabbing back to it. Your cursor will end up in the invisible first
name field and further shift-tabs can't move it past.
Cherry-picked from fx102: 080ada78ee
We can do it because it was only used to create a note from annotations.
No need to update schema version in Zotero client, unless using new
features when creating a note from annotations.