Closed Bug 1817731 Opened 1 year ago Closed 1 year ago

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

Categories

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

Thunderbird 111
Unspecified
All

Tracking

(thunderbird_esr102 unaffected, thunderbird111 wontfix, thunderbird112 wontfix, thunderbird113 wontfix, thunderbird114 fixed)

RESOLVED FIXED
115 Branch
Tracking Status
thunderbird_esr102 --- unaffected
thunderbird111 --- wontfix
thunderbird112 --- wontfix
thunderbird113 --- wontfix
thunderbird114 --- fixed

People

(Reporter: standard8, Assigned: darktrojan)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [Supernova3p])

Attachments

(2 files)

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).

See Also: → 1816741
Whiteboard: [Supernova]
Version: unspecified → Thunderbird 111

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.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX

(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.

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.

Duplicate of this bug: 1821518

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.

Duplicate of this bug: 1821932

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.)

Duplicate of this bug: 1823183

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.

Assignee: nobody → alessandro
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Duplicate of this bug: 1822954

(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?)
Flags: needinfo?(alessandro)

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

Flags: needinfo?(alessandro)

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.

See Also: → 1824555
Severity: -- → S3
OS: Unspecified → All
Priority: -- → P2
See Also: → 1829194
Whiteboard: [Supernova] → [Supernova3p]
Assignee: alessandro → geoff

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.

See Also: → 1834664
Status: REOPENED → ASSIGNED
Target Milestone: --- → 115 Branch

Pushed by mkmelin@iki.fi:
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

Status: ASSIGNED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED

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

thanks very much indeed.

Attachment #9335552 - Flags: approval-comm-beta?
Attachment #9335553 - Flags: approval-comm-beta?

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

[Triage Comment]
Approved for beta

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

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

Attachment #9335553 - Flags: approval-comm-beta? → approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: