RFE: Do not auto select next/previous message on message delete

REOPENED
Assigned to

Status

--
enhancement
REOPENED
12 years ago
a month ago

People

(Reporter: davek, Assigned: alta88)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gs] [penelope_wants] [dupeme] [see add-on in comment 37], URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: 8.0.0b1

After deleting a message, I like to return to the mailbox rather than see the next message.  In eudora classic this was an option.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

10 years ago
In Beta 7, this is worse, not better.

The behavior in Beta 6 and earlier:
1. Open a message in its own window.
2. Leaving the message window open, return to the window containing the mailbox.
3. In the mailbox view, delete the message that is open in its own window.
The message is deleted and the message window disappears. This is good.

The behavior in Beta 7:
1. Open a message in its own window.
2. Leaving the message window open, return to the window containing the mailbox.
3. In the mailbox view, delete the message that is open in its own window.
The message is deleted but the message window stays open and its contents change to the next message in the mailbox. This is bad.

Updated

9 years ago
Severity: enhancement → normal
Priority: -- → P3
Target Milestone: --- → Future

Comment 2

9 years ago
This is actually Thunderbird behavior so I am assigning this bug there (so that more people see it), with '[penelope_wants]' in the Whiteboard so that we can keep track of it.
Assignee: mozilla-bugs → nobody
Component: Mail Window → Message Reader UI
Product: Penelope → Thunderbird
QA Contact: mail-window → message-reader
Whiteboard: [penelope_wants]
Target Milestone: Future → ---
Version: unspecified → 3.0
(In reply to comment #1)
> The message is deleted but the message window stays open and its contents
> change to the next message in the mailbox. This is bad.

Try going to Tools -> Options (or Edit -> Preferences, or Eudora -> Preferences, or whatever it might be on your system) and opening the Advanced section, Reading & Display tab, and checking the box `Close message window on delete`.
Evidently the default for this pref changed in Thunderbird between Eudora 8.0b6 and 8.0b7.

I have the vague feeling that the rest of this bug* is probably a duplicate.


*This is not completely clear, by the way: where are the messages being viewed and deleted, respectively? from the preview pane and message pane? from a message window/tab and the message pane? from a message window/tab and the same window/tab?

If the message is being viewed in a window or tab, it doesn't seem to me to be helpful to do anything on deletion other than closing the window/tab, or moving to the next message.
If the message is being viewed in the preview pane, you could have an extra option to navigate the preview pane to the home page and deselect all messages, which is what it seems this bug is *probably* about.
Whiteboard: [penelope_wants] → [penelope_wants] [dupeme]

Comment 4

9 years ago
If I am looking at the list of messages in the Inbox folder and open one of these messages. I delete it while it is open. If there is another message in the list after this, it opens it.  If the message I deleted is the last one in the list,
the previous message is opened. This is not what I want. I would like it to merely
show the list of messages in the Inbox (or wherever I am), but not open another
message.
Refactoring summary per comment #4; moving to more accurate component. Developers may want to have a look at priority field, etc.
Severity: normal → enhancement
Component: Message Reader UI → Folder and Message Lists
OS: Windows Vista → All
QA Contact: message-reader → folders-message-lists
Hardware: x86 → All
Summary: return to mailbox on message delete → RFE: Pref not to select next/previous message on message delete
(Reporter)

Comment 6

9 years ago
The "close message window on delete" sounds like the right feature name but it's reversed.  I find that when focus in on the message list and I delete, the opened window with the message closes.

I'd like a feature to do the following.  I have a message open in a separate window (not in the preview window).  Focus on the message window.  Execute delete.  The message window closes and focus returns to the mailbox.  The newly selected message upon this action should be whatever the selected message would be if a delete was executed with focus on the message window.  I believe this is typically the next message down in the sorted mailbox list.

The reason for the request:  I don't necessarily read my mailbox in order.  Or I may have done a first pass and working my way back through follow-up items.  Also, I'm a keyboard shortcut user.  I'd like to arrow up/down in the mailbox to the message I want, press enter, and read the message.  When I'm done, delete the message and work my way through the mailbox list again.

Under the current operation it keeps opening the next message.  Then I have to close that message window.  And if "next" message was previously unread I have to mark that one as unread.  But maybe I'm not sure if it was unread ....
Dave, this last sounds like a separate bug. Can you search for it or file a new bug/enhancement? (Also, when you do, specific examples with made-up names help a lot in reducing possible confusion.)

Note that "close message window on delete" is intended to close whatever extra windows/tabs may contain the message that was deleted; it has nothing to do with selection.
(Reporter)

Comment 8

9 years ago
Hi Nathan,

It must be the same bug because I opened it.  :)  I opened it as an enhancement since it wasn't particularly a bug.  I believe the feature "close window on delete" showed up after I opened this feature request - I don't recall the time line precisely - note that it's against b1 (at least in my original comment).   It wasn't my intention to confuse the two.

Given that it is the same bug (enhancement), perhaps just poorly described the first comment, should it remain open?
Yes, Dave, I knew that. ;) What I meant was, it would be good to split it off into another bug for convenience of tracking -- when in doubt, file another bug, that's the general idea.

It seems like the others CCed on this bug are mostly looking for its current guise, so it would be good to split off anything that doesn't fit properly. No need to close this one, though: somebody may implement it, even if you don't need it. (When you do file it, make sure to CC me on it, would you?)

Make sense?
(Reporter)

Comment 10

9 years ago
Understood.  New Bug 543173.

Thanks for taking a look at it.  It's a most frequent action for me and therefore highly desired.  :)
Tb3 already has this option, it's the "close message window on delete". Bug 274628/bug 498141
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 274628

Comment 12

9 years ago
The same option is in Eudora 8, but it does not work.

Comment 13

9 years ago
Sorry, I jumped the gun. The deleted message window closes, but then it opens either the next message or, if the deleted was the last, it opens the previous message for that folder.

Comment 14

9 years ago
In Eudora 8 8b, the only difference I find in whether the "Close Message Window on Delete" option is set is that, if it is set, that message disappears completely.  If the option is not set, it is placed in the TRASH folder.
But the opening of the next/previous message occurs in either case.
(In reply to comment #11)
> Tb3 already has this option, it's the "close message window on delete". Bug
> 274628/bug 498141

Magnus, technically this is a different bug: this bug requests a pref to avoid *selecting* the next/previous message *in the message list* when the message is deleted (see comment #13, for example). Reopening for now.



(In reply to comment #14)
> In Eudora 8 8b, the only difference I find in whether the "Close Message 
> Window on Delete" option is set is that, if it is set, that message
> disappears completely.  If the option is not set, it is placed in the TRASH
> folder. But the opening of the next/previous message occurs in either case.

Hmm... sounds like Close Message Window on Delete is setting the wrong pref. The behavior sounds like that controlled by Account Settings -> <account> -> Server Settings -> When I delete a message:. Could you check that, please?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 16

9 years ago
OK, the only option I see under Server Settings is Leave Messages on Server and the the option under that Until I Delete Them.

I set both of these and the messages are staying on the server.  I delete them
in Eudora and after some time, they are deleted from the server.

Using the Close Message Window On Delete option, they are never left on the 
server.

Is this what you want or am I missing something?
Ah, sorry, I assumed you were using IMAP (which has different settings from POP3).

But this behavior is peculiar. Close Message Window on Delete shouldn't be able to affect delete behavior. Could you file that as a separate bug and link to it in a comment here?

Comment 18

9 years ago
I will re-test this again some more.  Because I can't duplicate what happened
in Comment 14.

Comment 19

9 years ago
OK, I give up. I must have been hallucinating.  No matter what the setting is
for the Close Message Window, deleting while the message is opened, it does to
the TRASH folder, and then opens the next/previous message in that folder.

It appears that the option either doesn't work, or it is doing something that I
am not seeing. I have also tried opening the message in a new message window
and also a new tab. I always have the existing window set.
The option is only intended to close the standalone window (or tab?) displaying a given message when that message is deleted (see bug 274628 for details).

This bug, if I understand correctly, is about not selecting any message at all after a given message is deleted.

Comment 21

9 years ago
yes to comment 20. I do not want to open another message when I have deleted one.
If this is an option, that is OK.  It is a nuisance to have to close another message when I don't want to. It is even worse when the next message is for my wife, and I then have to mark it as not read.  We use only one e-mail address
and still see no reason to have another.  Even if the next message is new and for
me, I want the option of leaving it as is until I am ready to look at it.
(In reply to comment #21)
> If this is an option, that is OK.  It is a nuisance to have to close another
> message when I don't want to. It is even worse when the next message is for my
> wife, and I then have to mark it as not read.  We use only one e-mail address
> and still see no reason to have another.  Even if the next message is new and
> for me, I want the option of leaving it as is until I am ready to look at it.

Note that there is an option (under Tools -> Options -> Advanced -> Reading & Display) to leave messages previewed in the message pane marked unread; this might be useful for most of the use case of this bug, though if someone dislikes using the preview pane, it wouldn't help anything.
Duplicate of this bug: 548994

Comment 24

9 years ago
I don't see the behavior described in Comment #20 (and confirmed in Comment #21) with "Close message window on delete" enabled.  The next message downward in the list is selected, but it does not open, and does not get marked "Read" -- at least, it doesn't with Message Pane off, and "Open messages in: a new window" selected (to make it more Eudora-like since the original reporter was using Eudora 8.0b1).  MacOS X 10.5.8, TB 3.1.1.

I'd say the operation desired in Comment #20 is achievable via the "Close message window on delete" option (note that this doesn't work if messages are opened in tabs -- see Bug 531534).

Comment 25

9 years ago
I'm having exactly the same problem. My settings are:

* I'm using IMAP
* Client is Eudora OSE 1.0
  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
* Message Pane is OFF
* Under "Options" -> "Advanced" -> "Reading & Display"
  - "Open messages in:" is set to "A new message window"
  - "Close message window on move or delete" is checked/activated

When I double-click on a message in order to read it, and then delete it afterwards, it opens and displays the next message in line in the same window. But I just want the message window to be closed when I delete the message (just like the "old"-eudora versions did years ago).

As mentioned before in Comment 19, I can't see what the function "Close message window on move or delete" does exactly either. No matter if this option is selected or not, the message window will never close on delete. I've also tested with "Open messages in" -> "A new tab" (I know, that shouldn't work at all according to Bug 531534) and "An existing message window". Everywhere the same behaviour... the message window never closes. That's very annoying...

Comment 26

9 years ago
I just tried this again, now on 3.1.2 (other info same as Comment #24); the window displaying the message is closed, the selector in the message-list window advances to the next message, but no window is opened.  

Is the desired behavior (and the subject of this RFE) that described in Comment #20, and if so, what would be the rationale for not selecting ANY message in the message list ?  Or is the desired behavior the negation of that described in Comment #21 (which would appear to me to be a bug) ?

Differences between my test and that of Comment #25: Message contained in "Local Folders" subfolder vs. IMAP folder, TB3.1.2 vs. TB3.0.4.

Bug 498141 (opened because "Close message window on delete" got broken) makes mention of the IMAP option to "just mark as deleted" somehow having an effect -- but it's not clear (without a much closer examination of the patch) whether the fix for Bug 498141 accommodated that case.  The last comment in Bug 498141 requests re-opening or that bug, indicating that the preference was still broken; Comment #21 and Comment #25 here indicate the same, based on an as-yet-to-be-determined condition (that I apparently don't have).

Comment 27

8 years ago
The "deletion behavior" tweak in the MailTweaks add-on is supposed to resolve this problem. However, any time Thunderbird 3.1.7 is restarted with MailTweaks enabled it starts up blank and unusable; MailTweaks needs to be disabled and Thunderbird restarted in order to use it. It would be much better if this functionality could be integrated into Thunderbird.

What I personally want is that when I delete a message, the NEXT unread message should open, until the end of the message list, at which time the message should close. It should never open PREVIOUS unread messages.

Comment 28

8 years ago
I'm hoping that this bug covers (and if corrected - would fix) - the issues that are preventing add-ons like "MailTweaks", “Unselect Message” and “After Delete” from working properly since introducing TB3. I just can't continue to allow TB3 to make the decision - to select the next message for me. IMO, It should just return to list with no message selected. Please, please put back the "hooks" needed by the extension developers to enable those add-ons to work correctly again - or please add this a a preference within TB3. Now that bug https://bugzilla.mozilla.org/show_bug.cgi?id=531534 is finally being addressed - this bug - more than ever - needs to remain open to address the second half of this issue.

Comment 29

8 years ago
I agree with Mr. Freeze. Although I don't use Mailtweak because it has issues with the undelete pref for me as well as others, I did use After Delete.

Being that I don't use tabs or open a message in a new window, it really is necessary in my opinion to continue with this bug report and allow the option to 'not select' the next/previous message upon delete when using the message pane.
(In reply to comment #28)
> I'm hoping that this bug covers (and if corrected - would fix) - the issues
> that are preventing add-ons like "MailTweaks", “Unselect Message” and “After
> Delete” from working properly since introducing TB3.

I'm 90% sure that no bug could cover that, since nothing in Thunderbird prevents this from happening. I haven't tried it, but I think this is the function add-on authors need to override to do this: http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#1305

Comment 31

8 years ago
(In reply to comment #30)
The extension developers have reported that the function "SetNextMessageAfterDelete" - no longer exists in TB3. Why it is no longer there or supportable - is not clear to me. I vote to bring back this function (if technically feasible)- and if this is the only reason why these add ons no longer function / or provide a Thunderbird written preference (and the code that goes along with it) - to control this behavior.
It's no longer there because the code was refactored to work better (or at least differently). As far as I am aware, there is still a simple function that one can override to do what you want. It just has a different name. The onus is on add-on developers to update their add-ons when new major versions of Thunderbird are released.

Comment 33

8 years ago
The last time I was looking at the After Delete extension, it was my understanding that the author did not know what needed to be changed and so gave up support. The Mail Tweak author, who seems to be mia now, was able to somewhat put together a feature not to select after delete, but there are problems with it being that the folderpane and the threadpane pane would be blank when that pref was enabled.

Can you help us Jim?

Comment 34

8 years ago
(In reply to comment #28)
I strongly concur with this issue. At least, in TB versions 1-2, "Unselect Message" took care of this problem. However, I've never understood why this option wasn't automatically included in TB to begin with.

I do not want TB making the decision to select any message upon delete (including marking junk) or at any other time. I prefer to leave messages as unread, until such time that I wish to read them. I feel that this is also a security issue, especially if I mark a message as "Junk" (which deletes the message) without reading it, only to have the next message (also Junk) to be automatically selected. 

Please put this on a higher priority basis and correct this flaw.

Comment 35

8 years ago
(In reply to comment #34)
> (In reply to comment #28)
> I strongly concur with this issue.
> 
> I do not want TB making the decision to select any message upon delete
> (including marking junk) or at any other time. I prefer to leave messages as
> unread, until such time that I wish to read them. I feel that this is also a
> security issue, especially if I mark a message as "Junk" (which deletes the
> message) without reading it, only to have the next message (also Junk) to be
> automatically selected. 
> 
> Please put this on a higher priority basis and correct this flaw.

Hear, hear! I just switched from TB2 to TB3 and am considering going back, just for this reason. 

I am reading my messages in the Message Pane (the one that you toggle with F8) and not in a separate window. I'm not reading them in order, eiher, I just single-click in the list. 

I'm using IMAP with the option "When I delete a message ..." set to "Just mark it as deleted".

When I select a message and the delete it, TB selects the next one and shows it in the message pane. I don't want that, for the same reasons as above (being marked as read when I don't want, security).

That was also how TB2 behaved, but at least I could work around it: with a "good" message selected and being shown in the message pane, right-click on a "bad" one and select "delete" from the context menu. Then compact the folder and the bad ones are gone.

Now (TB 3.1.10 on Linux) that doesn't work anymore. The "bad" one still gets marked read and deleted as before, but the message pane now shows the contents of the "bad" one ! (In TB2 the "good" one kept being displayed).

What's more - and this is definitely a bug - the message list and message pane are now out if sync: the bad one shows in the pane but the "good" one remains selected in the list ... so I can't even bring it back into the message pane by clicking on it. I have to select yet another one (say the "ugly"), thereby marking it as read, then go back to the "good" one and mark the "ugly" again as "unread".

So, what I want is simply an option to tell TB that the selection shouldn't move after deletion (and of course the message pane should always show the selected message - or nothing if there is none selected).

Comment 36

8 years ago
(In reply to comment #35)
> When I select a message and the delete it, TB selects the next one and shows it
> in the message pane. I don't want that, for the same reasons as above (being
> marked as read when I don't want, security).

I concur with this, I also want the last decision if a message (especially known spam/junk/virus) gets displayed in the message pane.

A basic Google search also shows, that users have brought up this topic several times, e.g.:
> http://www.wilderssecurity.com/showthread.php?t=277364
> http://getsatisfaction.com/mozilla_messaging/topics/automatic_opening_of_next_message_is_possible_security_weakness
Ok ok, I'll make an add-on to fix this (not that it bothers me personally). :)

Here it is: https://addons.mozilla.org/en-US/thunderbird/addon/deselect-on-delete/

For the curious, here's the code to do this (though you could obviously open up the .xpi to see it too):

FolderDisplayListenerManager.registerListener({
  onMessagesRemoved: function(display) {
    display._nextViewIndexAfterDelete = null;
  },
});

I'll leave this bug open just in case this ever gets into Thunderbird proper, but the issue should be resolved for most users now.
Whiteboard: [penelope_wants] [dupeme] → [penelope_wants] [dupeme] [see add-on in comment 37]

Comment 38

8 years ago
you rule hard, man! thanks a lot
Thank you!!! We've been waiting for this for years!

Comment 40

8 years ago
(In reply to comment #37)
> Here it is:
> https://addons.mozilla.org/en-US/thunderbird/addon/deselect-on-delete/

Hi,
it seems it does not work for me: in the 3 pane view, when I delete the current message, it selects the last message I read before (if it was above the deleted one) or the message next to the last read (if it was under the deleted message). It seems it remembers the line number of the previous read message...
Thnuderbirs 3.1.10
installed  add-ons:
CompactHeader 1.2.4
Deselect on Delete 1.0b1
Extra Folder Columns 1.1.3
Folderpane Tools 0.6
Lightning 1.0b2
MinimizeToTray Plus 1.0.8
MoreFunctionsForAddressBook 0.6.1
MR Tech Toolkit 6.0.4
Trier les dossier manuellement 0.6.6
Xpunge 0.4.1
Yet Another Mail Biff 0.8.0

Comment 41

8 years ago
Also does not work for me in three pane view.

Add-ons

Adblock Plus 1.3.6
DOM Inspector 2.0.9
Nightly Tester Tools 3.1.2
Toggle HTML Toolbar Button 0.6.0.8
Try updating the add-on to 1.0b2 (or downloading again if that doesn't work - I'm not sure if you can automatically update a non-reviewed add-on). I think I managed to outsmart the folder display. Anyway, to keep the noise in this bug down, post any issues you have with the add-on over here: https://bitbucket.org/squib/deselect-on-delete/issues?status=new&status=open

Comment 43

8 years ago
b2 works in three pane view!!!!

I've been waiting for this for a loooong time.

Comment 44

8 years ago
(In reply to comment #42)
> Try updating the add-on to 1.0b2 
Great! It seems iy works now. Thanks.

Updated

6 years ago
Whiteboard: [penelope_wants] [dupeme] [see add-on in comment 37] → [gs] [penelope_wants] [dupeme] [see add-on in comment 37]

Updated

6 years ago
Duplicate of this bug: 826710

Comment 46

6 years ago
I entered this as a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=826710

But it has been marked as a duplicate bug and redirects to this page which was created 2007-09-05

This bug has not been fixed in Thunderbird 17.0

I can only assume that because an Addon has been created to fix the problem that no action will be forthcoming.

Is it normal Thunderbird protocol to fix bugs and potential security threats by writing an Addon?

I have installed the Addon and it has fixed the issue. 
Jim Porter (:squib)...Thanks for providing the Addon :)

Comment 47

6 years ago
(In reply to Anje from comment #46)
I agree with you. It is very disappointing that nobody is working on this security related bug. I'm now waiting for years for a bugfix. An Addon could not be the final solution. :(

Updated

6 years ago
Priority: P3 → --

Comment 48

6 years ago
The helpful security Addon 'Deselect on Delete' is really useful but you can still get it to open next message under this circumstance;
Open and read a message then Delete, it doesn't open the next message. This is correct.
If while the message pane is empty, I Right click on another message and select Delete from drop down list, that message is deleted, but the next message in the list is then automatically opened. 
There is a loop hole..if the message has not been selected to display because perhaps you do not want to open it; so the Message Pane is empty, the rule does not apply.
Please can we have this fixed. 
Any idea when this security issue will be fixed?

Comment 49

6 years ago
In addition to the above comment:
The condition described in Comment 48 only occurs if the following is selected:
Tools > options > Advanced>Reading & Display tab
select: Close message window/tab on move or delete.
This isn't the place for bug reports about add-ons. For Deselect on Delete, you want <https://bitbucket.org/squib/deselect-on-delete/>. Please also try v1.1pre on that site (it's in the downloads section) to see if that fixes your issue.

Comment 51

4 years ago
Thunderbird not only should have the option to change this, but should act like this by default. This is the way gmail, outlook, and all the other big email clients work. Opening by default an email that you didn't want to open can be a BIG SECURITY ISSUE, despite being annoying too.

Updated

3 years ago
See Also: → bug 1221178

Updated

2 years ago
Duplicate of this bug: 1326536

Comment 53

a year ago
Extension "Enhanced Desktop Notifications" is marked as being compatible up to Thunderbird version 48, and I am now using version 52. This means that the primary work-around for this bug is no longer available.

Comment 54

a year ago
Sorry, in my previous comment I meant extension "Deselect on Delete" is marked as being compatible up to Thunderbird version 48, and I am now using version 52. This means that the primary work-around for this bug is no longer available.
> This means that the primary work-around for this bug is no longer available.

Not so. You can still install that add-on in newer versions of Thunderbird.

Comment 56

a year ago
In practice it is so. Normal users will not be able to install the extension. Even advanced users, such as myself, will not usually want to force installation. I just wouldn't trust it anymore. At the very least it takes extra time to research its actual status, and you have to know or suspect in advance that it would work fine. And there is the risk that it will stop in the future without any warning, or worse, causing trouble to the Thunderbird you rely on for your important e-mail communications. Not worth it for most of us.
To be honest, I wouldn't have trusted it for quite a while before this! I haven't even tested that add-on in a couple of years and have been considering just unlisting it, since I have more than enough other side projects to keep me busy. I've kept it around this long mainly because I don't get many support requests.

In any case, I updated compatibility on the add-on, but it looks like there's a bug in the add-ons code because it shouldn't be making installation difficult just because the add-on is old. It's not like the Thunderbird codebase changes that much.

If other people would like to maintain the add-on, just shoot me an email and we can discuss transferring ownership. (Before anyone asks, the add-on shouldn't just be ported to Thunderbird proper, since it uses black magic to do what it does.)

Comment 58

a year ago
The current Thunderbird situation in general, and this bug in particular, is really frustrating. But thanks for updating the add-on's compatibility.

Updated

4 months ago
Duplicate of this bug: 1511697
Comment hidden (advocacy)
Comment hidden (advocacy)
(Assignee)

Comment 62

4 months ago
The user deselected state must be respected, and no unwanted auto selection should happen on context menu delete, or marking as junk/junk column toggle, or message header button delete. No pref is necessary; if the message selection is cleared, prior selection is forgotten (overriding folder change remember pref) and no new selection is made.
Assignee: nobody → alta88
Attachment #9029379 - Flags: review?(jorgk)

Comment 63

4 months ago
Comment on attachment 9029379 [details] [diff] [review]
noSelectAfterDelete.patch

Sadly I know nothing about this, so Magnus is the better reviewer here.
Attachment #9029379 - Flags: review?(jorgk) → review?(mkmelin+mozilla)
Comment on attachment 9029379 [details] [diff] [review]
noSelectAfterDelete.patch

Review of attachment 9029379 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not sure this is addressing this RFE. 
For the imap mark-as-deleted model, it doesn't advance on delete, which really needs to remain the default way for sure. The behaviour is quite confusing otherwise, especially if reading through the separate message window. 
For other accounts, it seems to advance on delete just like it used to. Isn't this bug requesting it shouldn't?
Attachment #9029379 - Flags: review?(mkmelin+mozilla) → review-
(Assignee)

Comment 65

3 months ago
I should think we need to understand the use case rather than simply accept the proposed implementation at face value. Users want to signify for a message not to be auto selected on threadpane context/cycler column actions that remove a previous message. A global pref or even folder property is certainly the wrong way to go about this, as sometimes messages should be auto selected, and sometime not (as in a trash folder restoring or junking/deleting messages), and the same behavior is not necessarily consistently desired in the same folder at all times. So changing such a pref or property is very non ergonomic and imo such an implementation is a nonstarter.

The patch does not intend to change existing behavior at all when a message is selected, for either message window actions or the imap delete model or anything else. However, deselecting (ctrl-left click) a message is the method used to indicate the user does not want subsequent auto selection to happen. It's the best way to finely tune the behavior with 1 click.

I hope this makes the patch's intent clearer.
(Assignee)

Updated

3 months ago
Summary: RFE: Pref not to select next/previous message on message delete → RFE: Do not auto select next/previous message on message delete
(Assignee)

Updated

3 months ago
Attachment #9029379 - Flags: review- → review?(mkmelin+mozilla)
(Assignee)

Comment 66

3 months ago
Also, I think a selection column should be implemented in threadpane for mouse users, as is normal for very many mail list views. This would mean something like the excellent Checkbox Column extension https://addons.thunderbird.net/en-US/thunderbird/addon/checkbox-column/
(Assignee)

Comment 67

2 months ago

ping?

Comment on attachment 9029379 [details] [diff] [review]
noSelectAfterDelete.patch

Review of attachment 9029379 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to alta88 from comment #65)
> The patch does not intend to change existing behavior at all when a message
> is selected, for either message window actions or the imap delete model or
> anything else. 

Well it does. I agree a pref for something like this is not the way to go.
Sorry for the delay, but this bug is very confusing. Fine tuning the behaviour is fine by me, but I think you need to do it separately for each case. The current patch changes behaviours that shouldn't change.
Attachment #9029379 - Flags: review?(mkmelin+mozilla) → review-
You need to log in before you can comment on or make changes to this bug.