2071924 - Task list stops following the calendar after the unified toolbar customization has been open

Status: ASSIGNED

(Calendar :: Tasks, defect)

Description

[Airat Makhmutov]

Steps to reproduce

1. Open the Tasks space and create a task in a writable local calendar.
2. Right-click the unified toolbar, pick "Customize Mail Toolbar", press Save without changing anything.
3. Select the task, open it for editing, change the title, Save and Close.
4. Open the same task again, change the title, Save and Close.

Actual result
After step 3 the list still shows the old title. Step 4 fails with MODIFICATION_FAILED. Deleting a task leaves it in the list. Everything works again after a restart, until the customization is opened once more.

Expected result
The list keeps following the calendar, as it does before the customization is opened.

Reproduced on Thunderbird 155.0.1, Linux.

Comment 1

[Airat Makhmutov]

Attachment: Bug 2071924 - Restore the task tree observers when its frame is rebuilt. r?aleca

While the unified toolbar customization is open, #messengerBody is
display: none, so the task tree body frame is destroyed and
setTree(null) unregisters the observers that CalendarTaskTree.refresh()
had added. setTree() never registers them again when the frame comes
back, so the tree keeps its pre-customization items until restart, and
the edit dialog hands that stale copy to modifyItem() as the old item,
which storage rejects with MODIFICATION_FAILED.

refresh() is what registered the observers, it is idempotent, and it
also reloads the items missed while detached.

Verified on 155.0.1: with the fix the tree follows the calendar again
once the customization closes, two consecutive edits of one task both
succeed, and a deleted task disappears immediately.

Comment 2

[Airat Makhmutov]

Attachment: Bug 2071924 - Restore the task tree observers when its frame is rebuilt. r?aleca

The unified toolbar customization hides #messengerBody, which destroys
the task tree body frame and makes setTree(null) unregister the calendar
and preference observers. Nothing registered them again when the frame
came back, so the tree kept its pre-customization items and the edit
dialog handed one of them to modifyItem() as the old item, which the
provider rejects with a generation mismatch.

refresh() is what registered the observers, it is idempotent, and it
also reloads the items missed while detached.