Closed Bug 1959545 Opened 1 year ago Closed 1 year ago

Dragging a folder to a new parent doesn't insert at the expected position for IMAP folders

Categories

(Thunderbird :: Folder and Message Lists, defect, P2)

Thunderbird 139
defect

Tracking

(Not tracked)

RESOLVED FIXED
139 Branch

People

(Reporter: betterbird.project+18, Assigned: itagagaki)

References

Details

Attachments

(2 files, 1 external file)

Attached video re-order-video.mp4 —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 Edg/135.0.0.0

Steps to reproduce:

Dragging a folder to a new parent doesn't insert at the expected position, see video.
Maybe this patch for the previous version of the re-order functionality fixes this.

Blocks: 1957486

139.0a1 nightly 2025-04-04-10-03-46-comm-central-l10n

139.0a1 nightly 2025-04-04-10-03-46-comm-central-l10n is works fine as attached.
No need the patch for the previous version. See what ReorderFolderListener does.
https://hg-edge.mozilla.org/comm-central/rev/61cd87a2f6d0121a6784303b7c6b94e0e11939fc

So WORKSFORME?

Doesn't work in 139.0a1 (2025-04-09) (64-bit), we didn't make up the video artificially.

Sorry, forgot to say that the failure is for IMAP folders only. There seems to be some sort of timing issue since the folder doesn't exist until it's communicated by the IMAP server (or similar). Likely the same root cause as bug 82262.

Summary: Dragging a folder to a new parent doesn't insert at the expected position → Dragging a folder to a new parent doesn't insert at the expected position for IMAP folders

Reproduced.
IMAP in the folder pane is generally weird.
Various unexplained phenomena.
Not sure if this is related to bug 82262.
Will try to analyze the behavior reported in this bug.

Comment on attachment 9478172 [details]
re-order-video.mp4

These folders are under the IMAP server.

Comment on attachment 9478192 [details]
139.a1.2025-04-04-10-03-46-comm-central-l10n.mp4

These folders are under the Local Folders.

Okay, I've figured out why that happened.

I modified nsMsgCopyService::NotifyCompletion() to get the folder as a result of the move/copy operation.

For example, if the user drags and drops mailbox://nobody@Local%20Folders/test2/A to mailbox://nobody@Local%20Folders/test, the argument nsIMsgFolder* dstFolder will point to the folder
mailbox://nobody@Local%20Folders/test/A. (However, if A exists before the move/copy, the object will be named A(2), not A, after the dialog).
I wanted to keep this dstFolder to get it later with nsMsgCopyService::GetArrivedFolder().

The problem is that IMAP passes test instead of test/A as an argument dstFolder to this NotifyCompletion.

https://searchfox.org/comm-central/rev/9300037a76850ea56175b9ccc40142619a4f0b3c/mailnews/imap/src/nsImapMailFolder.cpp#5199-5202

if (srcFolder) {
  copyService->NotifyCompletion(m_copyState->m_srcSupport, this,
                                aExitCode);
}

Where this is the folder that received the drop.

This means that the NotifyCompletion interface is ambiguously defined, and one of them is misusing it.

What do you know about this?

The existing code for IMAP that I referenced in my previous comment needs to be modified to pass an object pointing to imap://user@host/test/A (in the example) instead of this (pointing to imap://user@host/test in the example) to NotifyCompletion().

However, I am not sure how to do this.

--
As a side note, if imap://user@host/test/A existed before the move, TB did not issue any dialog or error and did nothing with the move.
I think this should be improved.

Is this a regression?

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2

(In reply to Corey Bryant from comment #10)

Is this a regression?

It is hard to call this a regression. It did not break anything conventional. The problem is with the conventional code.
But until it is fixed, it can be called a regression.

Okay, I have a countermeasure. I'll submit the patch tomorrow.

Assignee: nobody → itagagaki
Status: NEW → ASSIGNED

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/0364f4954ff1
Dragging a folder to a new parent doesn't insert at the expected position for IMAP folders. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 139 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: