To allow creation of a standalone note with annotations from all the
selected top-level items and/or attachments. Annotations will be sorted
by the order of the items in the items list.
"Add Note from Annotations" remains when a single regular item or one or
more attachments under a single regular item are selected.
So that it works for more than two levels of items
Also fix a bug where the parent item could be returned more than once if
multiple child items were selected.
Built-in panes were creating a semi-invalid DOM in which the pane container and
the root element of the pane's XHTML got the same ID. There's no reason to give
containers IDs in the DOM, since we already have a Map of IDs to pane objects,
so let's just not.
- Fix sync and advanced preferences tests; use a new waitForFirstPaneLoad()
functions instead of the old paneload event listener
- Remove empty preferences_searchTest.js
- Rename some Zotero_Preferences members/functions for better clarity and
public/private differentiation
- Reorder, also for clarity
- Fix tabIndex parameter causing an error if invalid
- Remove window.sizeToContent() call in Sync.displayFields()
- So *that's* why the window resized every time the sync pane was loaded...
- Deprecate openURL() and simplify openInViewer()
A manual pane ID isn't often necessary, since you can just give a manual ID to
the root element in your XHTML. Let's make things a bit simpler for the caller
and reduce the potential for conflicts.
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.
