1817731 - Right-click and open in new tab/window on a folder switches the current tab to the folder as well

Status: RESOLVED FIXED

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

Description

[Mark Banner (:standard8)]

STR:

1. Start up Thunderbird
2. Select a folder in the left-hand pane.
3. Right click on a different folder
4. Select "Open in new tab" (or Window).

Expected Results

The original tab stays on the same folder.

Actual Results

Both tabs are on the folder that was right-clicked in step 3 (the folder changes as soon as you right click).

Comment 1

[Alessandro Castellani [:aleca]]

This is not a bug, this was done on purpose.
We removed the "right click doesn't change the selection" behaviour for UX consistency and code simplicity.
Now the right click always changes the selection.
We know that this will catch some users by surprise, but it shouldn't be a blocker to any particular behaviour, just a bit annoying in terms of muscle memory.

Comment 2

[Mark Banner (:standard8)]

(In reply to Alessandro Castellani [:aleca] from comment #1)

We know that this will catch some users by surprise, but it shouldn't be a blocker to any particular behaviour, just a bit annoying in terms of muscle memory.

Whilst I understand about simplicity, I disagree with "this is not a blocker to a particular behaviour". The behaviour is that I'm looking at an email, and decide to want to look at a folder in a new tab/window as I want to refer between the two. With the new behaviour, I have to select the new folder, open the tab, then switch back to my original tab, reselect the original folder, then reselect the message.

For reference, Mac's Finder application allows you to right-click on folders and open then in new tabs without selecting them. I haven't used Windows recently, so I can't say what that does.

Comment 3

[Alessandro Castellani [:aleca]]

Indeed, the OSs are very inconsistent with this.
For example on macOS, it behaves as you said while using the "list" view in the Finder, but not in the "icons" view (not sure how it's called).
Some Linux DEs behaves the same, depending if the file explorer is in icon view or list view.
Windows dropped that entirely and now always selects on right click, regardless of the view.

There are many UX researches and analysis about this behaviour and the general consensus is that "right click to temporarily select" is a paradigm that should be dropped because it creates a temporary state that doesn't reflect the reality of the selection state, and it's exclusively mouse-centric.

If we get many bug reports about this, we can consider implementing it back.

Comment 5

[Calum Mackay]

That's extremely disappointing, and seems a real regression.

I might have various messages selected, and a quick-filter-bar search (including body) showing results that took some time to find (huge folder).

If I then want to check something in another folder, I don't want to disturb the above state. But with the new behaviour, all my state above is lost, when I right-click on a new folder in other to open it in a new tab. That's infuriating!

It would be a lot less annoying were there any other way to open a new (empty) tab, in which I could then select the new folder, but I don't see a way to do that; File—New doesn't have a tab entry.

So now I'm having to keep a "dummy" tab open, to which I can switch and then right-click a new folder in it, so as not to disturb the state in my other tabs. That's a waste of tab space.

Comment 7

[gene smith]

It also does an imap SELECT on that right-clicked folder. And unless you open the right-clicked folder in it's own tab or window, you lose your view of the currently open folder. To me it seems like a bug.
(Sorry for the dupe. I didn't look for "RESOLVED" bugs.)

Comment 9

[Alessandro Castellani [:aleca]]

Reopening this ans snatching it because after more research there's not a definitive good/bad UX decision on this behavior.
It's something that many OSs are definitely sunsetting, but for now we should re-implement it.

Comment 11

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani [:aleca] from comment #9)

Reopening this ans snatching it because after more research there's not a definitive good/bad UX decision on this behavior.
It's something that many OSs are definitely sunsetting, but for now we should re-implement it.

• Probably okay to revert to the legacy behaviour "right-click does not select" for the folder list, that may be practical and helpful.
• What about the message list? Feels more weird there, but perhaps also useful? Personally, I'm a bit worried about ux-error-prevention, sometimes right-click will act on a single message, but sometimes right-click will act on all selected messages. Needs a lot of attention I guess, but well, that's always true for selecting things. Otoh, iirc, we haven't had many complaints about the legacy behaviour.
• Or should we give users a choice? (Since we already have the new behaviour implemented, and want to restore the old behaviour, we might be able to add a switch between the two?)

Comment 12

[Alessandro Castellani [:aleca]]

We're putting back the legacy behavior for both folders and messages, no need to add a pref and complicate things.

Comment 13

[MM]

Please keep bug 507541 in mind. The code to fix this was just removed under the assumption that one can only answer the displayed message ("no right-click reply"). If right- click doesn't select any more, replying to a different message becomes possible again. Code added here, code removed here. Adding an equivalent check may be necessary.

Comment 14

[gene smith]

Here's another reason I've noticed with recent dailies why this should be fixed:

• Delete a ton of messages to Trash folder
• Right-click on Trash to empty trash

Previously (110 or earlier) this caused minimal imap network activity (mark every message deleted, do expunge).
Now if you right-click on Trash it also selects the folder causing all the headers from the imap server to be downloaded. If you are using offline store for trash, autosync may also cause the full messages to be downloaded before the empty process can begin.

This became more apparent while I was testing to confirm bug 1833665 and bug 1834056.

Comment 15

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1817731 - Allow right-clicking on the folder tree without changing selection. r=aleca

Comment 16

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1817731 - Test that the folder pane context menu operates on the right folder. r=aleca

Depends on D178877

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3c5d84680a28
Allow right-clicking on the folder tree without changing selection. r=aleca
https://hg.mozilla.org/comm-central/rev/624fb3c14327
Test that the folder pane context menu operates on the right folder. r=aleca

Comment 18

[Calum Mackay]

Confirmed working now for me in 115.0a1 (2023-05-25) (64-bit); MacOS 13.3.1 (a) (22E772610a)

thanks very much indeed.

Comment 19

[Wayne Mery (:wsmwk)]

Comment on attachment 9335552 [details]
Bug 1817731 - Allow right-clicking on the folder tree without changing selection. r=aleca

[Triage Comment]
Approved for beta

Comment 20

[Wayne Mery (:wsmwk)]

Comment on attachment 9335553 [details]
Bug 1817731 - Test that the folder pane context menu operates on the right folder. r=aleca

[Triage Comment]
Approved for beta

Comment 21

[Daniel Darnell [:dandarnell]]

Thunderbird 114.0b6:
https://hg.mozilla.org/releases/comm-beta/rev/30ae33bb0660
https://hg.mozilla.org/releases/comm-beta/rev/79777e03dc80