Closed Bug 1825430 Opened 1 year ago Closed 1 year ago

Renaming or moving a folder makes its subfolders disappear


(Thunderbird :: Mail Window Front End, defect)

Thunderbird 112


(thunderbird_esr102 unaffected, thunderbird113 fixed)

114 Branch
Tracking Status
thunderbird_esr102 --- unaffected
thunderbird113 --- fixed


(Reporter: neil, Assigned: darktrojan)


(Blocks 1 open bug)


(Keywords: regression, Whiteboard: [Supernova3p])


(3 files)

Steps to reproduce problem:

  • Create a profile with a local folders account
  • Create folder Local Folders/Folder1
  • Create folder Local Folders/Folder1/Folder2
  • Create folder Local Folders/Folder1/Folder2/Folder3
  • Rename Folder2 to Folder4
  • Note that Folder3 disappears
  • Move Folder1 to Trash
  • Note that Folder4 disappears

Confirmed on daily.

Ever confirmed: true
Keywords: regression
Whiteboard: [Supernova]
Assignee: nobody → geoff

This is what I'm using to work around the bug. I've only tested on the "all" view; I don't use the other views so I don't know what the expected behaviour there is.

There is still an issue in that renaming or moving a folder always expands it. This appears to be because of the way the new code handles expansion persistence; the old code used the folder flag nsMsgFolderFlags.Elided which is set when the folder is collapsed; the various rename and move functions copy the flags to the new folder so that the collapsed state was persisted through a move or rename. (This applies to any collapsed subfolders as well of course.)

Yeah, that's the same way I'm going to fix it. I'm dealing with the other modes and having a fight with a test at the moment.

We've handled the expansion differently for a while now, it's not new or I wouldn't have done it this way. I don't know when or why it changed, I just copied what was there. Although I will admit it's not perfect and I'll have a look into using the flag as well/instead of it. But probably not in this bug.

Sorry, I wasn't meaning to suggest that you had to use the flag, I was just comparing it with when I last tried it; I hadn't realised you'd previously introduced the opposite bug whereby all the folders collapse when you move rename or move then.

This just makes checkModeListItems async and adds a timeout so that the call to expand all rows actually works. Done as a separate patch for readability.

We have a problem here because the back end doesn't tell us about subfolders of folders that were moved or renamed.
At the moment I'm most concerned about getting the behaviour right and tested, so that future changes to fix and clean up this code don't break things.

Depends on D175204

Pushed by
Minor improvement browser_folderTreeQuirks.js. r=leftmostcat
Fix what the folder tree does if a folder is renamed or moved. r=elizabeth

Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch
Attachment #9328072 - Flags: approval-comm-beta?
Attachment #9328073 - Flags: approval-comm-beta?

Comment on attachment 9328072 [details]
Bug 1825430 - Minor improvement browser_folderTreeQuirks.js. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Attachment #9328072 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9328073 [details]
Bug 1825430 - Fix what the folder tree does if a folder is renamed or moved. r=elizabeth

[Triage Comment]
Approved for beta

Attachment #9328073 - Flags: approval-comm-beta? → approval-comm-beta+
Whiteboard: [Supernova] → [Supernova3p]
You need to log in before you can comment on or make changes to this bug.