Closed Bug 1838489 Opened 1 years ago Closed 1 years ago

When dragging a message or folder over a folder or account it expands, but, if nothing dropped, it never collapses

Categories

(Thunderbird :: Folder and Message Lists, defect)

Thunderbird 112
defect

Tracking

(thunderbird_esr102 unaffected, thunderbird115+ affected)

RESOLVED FIXED
116 Branch
Tracking Status
thunderbird_esr102 --- unaffected
thunderbird115 + affected

People

(Reporter: gds, Assigned: mkmelin)

References

(Blocks 2 open bugs, Regressed 1 open bug, )

Details

(Whiteboard: [Supernova3p])

Attachments

(3 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #1825372 +++

While testing my changes involving folder move/copy via context and by d&d (Bug 1831759 and Bug 1828372), I kept noticing something that I couldn't remember seeing before. When I drag a folder or a message over a collapsed folder it expanded and when I dragged over a collapsed account it expanded. Even if I didn't drop anything into a folder I ended up with a lot of expanded folders and accounts cluttering the folder pane.

I have a lot of nested folders and accounts, mostly for test purposes, which makes this issue quite noticeable.

I compared it to 102 behavior and it also does the auto-expansion but if I don't drop anything and move on, the folders and accounts auto-collapse and I don't end up with a lot of expanded folders and accounts. I think maybe the 102 time to expanded is a bit longer (more than the current 500 ms) but not sure. I don't see the auto-collapse with the current CC tip version, so I have to manually collapse the folders/accounts.

Then I checked the about3Pane.js "blame" and found bug 1825372 which adds the missing auto-expand on drag-over feature but it doesn't seem to do auto-collapse.

FWIW, user Richard Leger told me via email that he sometimes sees his folders and accounts expanded and he didn't intentionally expand them. It may be possible he is seeing this issue too (but he didn't mention anything about dragging over the folders/accounts).

Steps to reproduce:

Dragged another folder or a message to over another account or another folder that contains subfolders. If I remain over that account or folder for more than .5 seconds it auto-expands. I decide I don't want to put the folder or message there and move on to over another account or folder. It also auto-expands.

Actual results:

I end up with a lot of expanded accounts and/or folders.

Expected results:

If I don't drop the folder or message into the auto-expanded account or folder, it should auto-collapse as occurs with tb 102.

Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Target Milestone: --- → 116 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/c4547ef76710
On drop, auto-expanded folders should re-collapse again. r=john.bieling

Status: ASSIGNED → RESOLVED
Closed: 1 years ago
Resolution: --- → FIXED

With this patch the behavior when dropping a message is now the opposite of 102 behavior.

  • With 102, when you drop a message into an auto-expanded folder sub-tree, the sub-tree remain expanded and you still see the destination folder after the drop..
  • With this patch, when you drop a message into an auto-expanded folder sub-tree, the sub-tree collapses and you don't see the destination folder after the drop.

This patch also doesn't address the other changes from 102 behavior:

  • With 102, if you drag your selection over several folders and/or accounts, they all auto-expand, but if you don't drop and instead drag the selection off of the folder pane, all the folders and/or accounts auto-collapse back to their original state, even after the mouse button is released.
  • With this patch, if you drag your selection over several folders and/or accounts, they all auto-expand, and if you don't drop and instead drag the selection off of the folder pane, all the folders and/or accounts remain expanded and don't collapse back to their original state, even after releasing the left (for dragging) mouse button.

I would also add the ability to fold an expanded folder when drag over but not dropped so to allow to reach quickly a folder that may be located further down below it.

For example if I have a Inbox > Folder 1 expanded with 100 sub-folder, I could drag message selection onto Folder 1 to have it collapse and allow me quicker drag to an Inbox > Folder 2 that may be located underneath. See below example.

Before I drag message selection it may look something like the below with a long list of SubFolder(s) in Folder 1

Inbox
  v Folder 1
         SubFolder 1
         SubFolder 2
         ...
         ...
         ...
         SubFolder 100
  > Folder 2

If I drag the selection over Folder1 I would expect it to fold as shown below, so I can quickly drag and drop my selection to Folder 2 (much shorter dragging distance).

Inbox 
  > Folder 1
  > Folder 2

In a similar way, if during a selection drag I select folded Folder 1 by mistake and it expanded, I should be able to fold it back while drag away the selection (and back on Folder 1?) to reach Folder 2 more easily as Folder 1 would simply re-fold when drag upon it.

If we take 102 functionality as the goal, and we assume Folder 1 is already manually expanded before the drag starts, it never auto-collapses like you would want. So that would be a UI change in function and require some discussion to justify, I think

However, your 2nd proposal,

In a similar way, if during a selection drag I select folded Folder 1 by mistake and it expanded, I should be able to fold it back while drag away the selection (and back on Folder 1?) to reach Folder 2 more easily as Folder 1 would simply re-fold when drag upon it.

already occurs in 102, sort-of (if I understand your request correctly). With 102, If you drag over Folder 1 and it auto-expands and fills the screen such that you can't see Folder 2, you can auto-collapse Folder 1 by dragging off of the folder pane back over to the thread pane or summary pane. This will auto-collapse Folder 1 back to its original state so you can continue dragging to Folder 2 which will auto-expand so you can drop into a sub-folder of Folder 2.

This is what is missing still from the 115 branch: Once a folder or an account auto-expands when dragged over, it never auto-collapses back to its initial state no matter what you do.

This shows a small problem when dragging a message onto a folder that needs to be auto-expanded to see the sub-folders. I'm trying to drag the message into Archives and I miss the target slightly and Archives folder fails to expand. I then carefully go down to another expandable folder, Mike, and it expands. I then move back to Archive and it finally expands.
I found a fix for this by commenting out the return line:
https://searchfox.org/comm-central/rev/1440828fbb8871310c3c60b9db042d1ed7214041/mail/base/content/about3Pane.js#2703 so the timer fires for all folders, not just those that are initially collapsed. I'm sure there's a better way to fix this.
I see this with 115b5 as well as with my self-built daily.

Attached patch partial-fix-about3Pane.diff (obsolete) (deleted) — Splinter Review

Here's a possible way to more closely approximate 102 behavior with changes in about3Pane.js. With this change, all the folders that get auto-expanded when dragged over are saved in an _rowArray[]. Then if the user decides not to drop the message into a folder and moves the selection back to the threads pane, all the previously expanded folders and accounts collapse.

Also, unlike current 115/116 behavior introduced by comment 1 patch above, when a drop occur into an auto-expanding folder, no collapse occurs.

With this diff, the only difference with 102 is that dragging the selection back to the message display pane with 102 also collapses all the folders that got expanded due to the drag-over. I couldn't find any handling of the message display pane in about3Pane.js so, with this diff, dragging over it does not collapse the folders as it does with 102. So with this change you have to explicitly drag back over to the thread pane to collapse the folders.

Attached patch fix-about3Pane.diff (deleted) — Splinter Review

Added dragover event handling for messageBrowser, multiMessageBrowser and webBrowser -- the three incarnations of the message viewing pane. This now enables identical behavior to 102, I think.

Attachment #9340850 - Attachment is obsolete: true

(In reply to gene smith from comment #8)

This now enables identical behavior to 102, I think.

There is still another problem with my proposed change, so not "identical" to 102. When you select a different folder, the message pane is set to empty/cleared. v102 does this too. But with the current version, there is no "dragover" event when dragging a message in the blank message pane. The dragover event only occurs in the message pane when there is something displayed in the message pane (e.g., a message). Therefore it's not possible to auto-collapse an auto-expanded folder by dragging into the message pane when it's empty; the message must be fully selected and opened first for auto-collapse on drag into message pane to work. (Dragging back to the thread pane still does do the auto-collapse when message pane is empty.)
With 102, when the "mousedown" event occurs when selecting or when starting to drag a message, the message is immediately displayed in the message pane without requiring that the mouse switch be released. This does not occur with the current versions which selects and opens the message only after the mouseup event. So if "mousedown" selected and opened the messages in the current version (as it did with 102) this problem would not exist.

Blocks: 1840484
Regressions: 1840484
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: