Upgrade StorageEditing a child note makes expanded parent item attachment rows flicker
Title:
Editing a child note makes expanded parent item attachment rows flicker
### Description
In Zotero 9.0.4 on Windows, editing/saving a child note under a regular item causes visible child rows under the same expanded parent item to briefly disappear/reappear. In practice, the parent item's PDF attachment row appears to "jump" or flicker in the middle item tree while typing in or saving the note.
This appears to be Zotero core behavior, not an extension issue. I reproduced/observed the same behavior with relevant extensions disabled. It also still happens with attachment preview disabled/collapsed:
extensions.zotero.showAttachmentPreview = false
extensions.zotero.panes.attachments.open = false
Steps to reproduce
Use a regular Zotero item that has at least one PDF attachment and one child note.
In the middle item tree, expand the parent regular item so the PDF attachment row and note row are visible.
Edit/save the child note.
Watch the PDF attachment child row under the same parent item.
Actual behavior
The PDF attachment child row briefly jumps/flickers.
A debug log from the save shows:
Notifier.trigger('modify', 'item', [], { ... noteEditorID ... })
UPDATE itemNotes SET parentItemID=?, note=?, title=? WHERE itemID=?
Loading childItems for 1 item
Sorted 1 child items by parent toggle
The relevant Zotero code appears to be in chrome/content/zotero/itemTree.js. For child items, sort(itemIDs) closes and reopens the parent row:
// For child items, just close and reopen parents
this._closeContainer(row, true, true);
this.toggleOpenState(row, true, true);
Zotero.debug(`Sorted ${numSorted} child items by parent toggle`);
Since the parent row is expanded, this removes and reinserts all visible child rows, including the PDF attachment row, which creates the visual flicker.
There is also a secondary refresh chain in chrome/content/zotero/elements/attachmentsBox.js: the attachments box registers an item notifier and notify() calls _updateAttachmentIDs(), which calls getAttachments(true) and getBestAttachment() even when showAttachmentPreview is false. But the visible "PDF row jump" described here is best explained by the item tree parent close/reopen behavior above.
Expected behavior
Editing the content of a child note should not cause the expanded parent item to be closed and reopened, because note content edits do not normally change the ordering or visibility of sibling child rows such as PDF attachments.
Ideally, for a plain child-note content modification, Zotero would update/invalidate only the affected note row and any necessary parent counts/cache, without toggling the expanded parent container. If a note title or parent changes in a way that affects sorting/visibility, then a more complete child-row refresh would make sense.
Environment
Zotero: 9.0.4
OS: Windows
Editing a child note makes expanded parent item attachment rows flicker
### Description
In Zotero 9.0.4 on Windows, editing/saving a child note under a regular item causes visible child rows under the same expanded parent item to briefly disappear/reappear. In practice, the parent item's PDF attachment row appears to "jump" or flicker in the middle item tree while typing in or saving the note.
This appears to be Zotero core behavior, not an extension issue. I reproduced/observed the same behavior with relevant extensions disabled. It also still happens with attachment preview disabled/collapsed:
extensions.zotero.showAttachmentPreview = false
extensions.zotero.panes.attachments.open = false
Steps to reproduce
Use a regular Zotero item that has at least one PDF attachment and one child note.
In the middle item tree, expand the parent regular item so the PDF attachment row and note row are visible.
Edit/save the child note.
Watch the PDF attachment child row under the same parent item.
Actual behavior
The PDF attachment child row briefly jumps/flickers.
A debug log from the save shows:
Notifier.trigger('modify', 'item', [], { ... noteEditorID ... })
UPDATE itemNotes SET parentItemID=?, note=?, title=? WHERE itemID=?
Loading childItems for 1 item
Sorted 1 child items by parent toggle
The relevant Zotero code appears to be in chrome/content/zotero/itemTree.js. For child items, sort(itemIDs) closes and reopens the parent row:
// For child items, just close and reopen parents
this._closeContainer(row, true, true);
this.toggleOpenState(row, true, true);
Zotero.debug(`Sorted ${numSorted} child items by parent toggle`);
Since the parent row is expanded, this removes and reinserts all visible child rows, including the PDF attachment row, which creates the visual flicker.
There is also a secondary refresh chain in chrome/content/zotero/elements/attachmentsBox.js: the attachments box registers an item notifier and notify() calls _updateAttachmentIDs(), which calls getAttachments(true) and getBestAttachment() even when showAttachmentPreview is false. But the visible "PDF row jump" described here is best explained by the item tree parent close/reopen behavior above.
Expected behavior
Editing the content of a child note should not cause the expanded parent item to be closed and reopened, because note content edits do not normally change the ordering or visibility of sibling child rows such as PDF attachments.
Ideally, for a plain child-note content modification, Zotero would update/invalidate only the affected note row and any necessary parent counts/cache, without toggling the expanded parent container. If a note title or parent changes in a way that affects sorting/visibility, then a more complete child-row refresh would make sense.
Environment
Zotero: 9.0.4
OS: Windows
The Debug ID: D521110839.