Have option to not automatically open next email

Bug #1653351 reported by Wise Melon
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Confirmed
Unknown
Ubuntu GNOME
Confirmed
Undecided
Unassigned
thunderbird (Ubuntu)
Triaged
Low
Unassigned

Bug Description

I have found that with Thunderbird if I open an email and then press a button such as the "Junk" or "Delete" button, it will automatically move on and open the next email. Now as I get a lot of spam on this email in the inbox with the spam filter not properly configured yet, it would be very useful if there were an option to disable this automatically opening the next email feature. So that it would just go to the blank screen in the email display section. Quite a few people I know for similar reasons say they would like an option like this so that malicious emails don't accidentally get opened.

Revision history for this message
In , Davek-7 (davek-7) wrote :

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.

Revision history for this message
In , Cstobbe (cstobbe) wrote :

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.

Revision history for this message
In , Mdudziak (mdudziak) wrote :

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.

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

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

Revision history for this message
In , Hartung-m (hartung-m) wrote :

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.

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

Refactoring summary per comment #4; moving to more accurate component. Developers may want to have a look at priority field, etc.

Revision history for this message
In , Davek-7 (davek-7) wrote :

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

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

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.

Revision history for this message
In , Davek-7 (davek-7) wrote :

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?

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

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?

Revision history for this message
In , Davek-7 (davek-7) wrote :

Understood. New Bug 543173.

Thanks for taking a look at it. It's a most frequent action for me and therefore highly desired. :)

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Tb3 already has this option, it's the "close message window on delete". Bug 274628/bug 498141

*** This bug has been marked as a duplicate of bug 274628 ***

Revision history for this message
In , Hartung-m (hartung-m) wrote :

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

Revision history for this message
In , Hartung-m (hartung-m) wrote :

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.

Revision history for this message
In , Hartung-m (hartung-m) wrote :

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.

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

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

Revision history for this message
In , Hartung-m (hartung-m) wrote :

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?

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

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?

Revision history for this message
In , Hartung-m (hartung-m) wrote :

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

Revision history for this message
In , Hartung-m (hartung-m) wrote :

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.

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

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.

Revision history for this message
In , Hartung-m (hartung-m) wrote :

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.

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

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

Revision history for this message
In , Nathan Tuggy (tuggyne) wrote :

*** Bug 548994 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Mike001 (mike001) wrote :

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

Revision history for this message
In , Bugzillr (bugzillr) wrote :

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

Revision history for this message
In , Mike001 (mike001) wrote :

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

Revision history for this message
In , Mozilla-5 (mozilla-5) wrote :

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.

Revision history for this message
In , Mrfreeze-e (mrfreeze-e) wrote :

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.

Revision history for this message
In , U382332 (u382332) wrote :

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.

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

(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

Revision history for this message
In , Mrfreeze-e (mrfreeze-e) wrote :

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

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

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.

Revision history for this message
In , U382332 (u382332) wrote :

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?

Revision history for this message
In , Dontyouread (dontyouread) wrote :

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

Revision history for this message
In , W-mozilla (w-mozilla) wrote :

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

Revision history for this message
In , Jp-lilien (jp-lilien) wrote :

(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

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

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.

Revision history for this message
In , Sholzers (sholzers) wrote :

you rule hard, man! thanks a lot

Revision history for this message
In , Sammy (s-zas) wrote :

Thank you!!! We've been waiting for this for years!

Revision history for this message
In , Carminou (carminou) wrote :

(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

Revision history for this message
In , Rvjanc (rvjanc) wrote :

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

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

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

Revision history for this message
In , Rvjanc (rvjanc) wrote :

b2 works in three pane view!!!!

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

Revision history for this message
In , Carminou (carminou) wrote :

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

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

*** Bug 826710 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Anjeyelf (anjeyelf) wrote :

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

Revision history for this message
In , Knight-g (knight-g) wrote :

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

Revision history for this message
In , Anjeyelf (anjeyelf) wrote :

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?

Revision history for this message
In , Anjeyelf (anjeyelf) wrote :

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.

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

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.

Revision history for this message
In , U474331 (u474331) wrote :

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.

Revision history for this message
In , Vseerror (vseerror) wrote :

*** Bug 1326536 has been marked as a duplicate of this bug. ***

Changed in thunderbird:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Revision history for this message
In , Rdiezmail-mozilla (rdiezmail-mozilla) wrote :

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.

Revision history for this message
In , Rdiezmail-mozilla (rdiezmail-mozilla) wrote :

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.

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

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

Revision history for this message
In , Rdiezmail-mozilla (rdiezmail-mozilla) wrote :

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.

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

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

Revision history for this message
In , Rdiezmail-mozilla (rdiezmail-mozilla) wrote :

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

Revision history for this message
gf (gf-interlinks-deactivatedaccount) wrote :

Hello Wise,
Thank you for submitting this bug and reporting a problem with Thunderbird. You made this bug report in 2016 and there have been several versions of Ubuntu and Thunderbird since then.

Could you confirm that this is no longer a problem and that we can close the ticket?
If it is still a problem, are you still interested in finding a solution to this bug?
If you are, could you run the following (only once):
apport-collect BUGNUMBER
and upload the updated logs and and any other logs that are relevant for this particular issue.

Thank you again for helping make Ubuntu and Thunderbird better.
G

Changed in ubuntu-gnome:
status: New → Incomplete
Changed in thunderbird (Ubuntu):
status: New → Incomplete
Revision history for this message
In , Vseerror (vseerror) wrote :

*** Bug 1511697 has been marked as a duplicate of this bug. ***

Revision history for this message
In , LonelyPixel (nospam-unclassified) wrote :

Is it still normal that missing and much-requested features, that are even extremely simple to implement and solution code has already been provided, are just left out only because there is an add-on that drops out of compatibility every couple years? That add-on was even considered being removed from the author, taking us back 9 years. That's just ridiculous.

Is there any statement from the development team that clearly says that the requested behaviour is not desired or acceptable in Thunderbird and cannot be added for whatever reason? I mean this whole discussion and all the time it eats up could immediately come to an end when the couple lines of code shown a few years ago would just be copied into the Thunderbird source code. It's really not that hard. And it doesn't take Thunderbird developers much time to just do it. Yes, this is all open source and extensible in a way, but we're mostly users. We can neither fork and compile Thunderbird on a regular basis nor patch extensions every now and then, and maybe even fix them for newer Thunderbird versions because something in the application was changed and nobody took care of this add-on feature (because it's not in the core).

All in all, this discussion just adds to my impression of the dead Thunderbird. Nothing happens round here anymore. New versions don't bring me any benefits. I cannot remember a single thing that I was happy about in the last years' new Thunderbird releases. Nothing that would help me or improve the situation we're in. It's just useless. So for now I'll just stick with Thunderbird 52 and disable the anoying upgrade check that would only take away required features, again.

Revision history for this message
In , Anjeyelf (anjeyelf) wrote :

Current auto setting in Thunderbird works on the belief that deciding to delete a message means the user wants to automatically open the next message which occupies the updated position in the message list.

Perhaps the developers decide that the user is currently reading emails and therefore wants to auto open next message. As I have sort by descending this means opening an older message which may or may not have been read.

It would be helpful, if the developers could offer users the option to auto open an email upon delete. This option could be placed in the same location as where you decide how to open an email in eg: tab etc.
OR it could be offered as a Tool, to switch auto opening on delete on or off.

At this point, after many years and much discussion, I'm stil none the wiser as to why this much requested and reasonable request has not been done.

Is there someone willing to undertake this issue and finally include it as an option in thunderbird?

Revision history for this message
In , Alta88 (alta88) wrote :

Created attachment 9029379
noSelectAfterDelete.patch

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.

Revision history for this message
In , Jorg K (jorgk) wrote :

Comment on attachment 9029379
noSelectAfterDelete.patch

Sadly I know nothing about this, so Magnus is the better reviewer here.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Comment on attachment 9029379
noSelectAfterDelete.patch

Review of attachment 9029379:
-----------------------------------------------------------------

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?

Revision history for this message
In , Alta88 (alta88) wrote :

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.

Revision history for this message
In , Alta88 (alta88) wrote :

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/

Revision history for this message
In , Alta88 (alta88) wrote :

ping?

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Comment on attachment 9029379
noSelectAfterDelete.patch

Review of attachment 9029379:
-----------------------------------------------------------------

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

Revision history for this message
Paul White (paulw2u) wrote :

Marking issue confirmed as there is now a duplicate and the issue is being discussed upstream.

Changed in thunderbird (Ubuntu):
status: Incomplete → Confirmed
Changed in ubuntu-gnome:
status: Incomplete → Confirmed
Changed in thunderbird:
importance: Wishlist → Medium
Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

Just a small update: my add-on mentioned in comment 37 no longer works due to the changes in the add-ons API. Sadly, I don't have time to fix this since I already have too many things on my plate. This means that there's not really any existing solution for this bug for TB 78 users.

Some sort of fix along the lines of the attached patch (i.e. something that doesn't require setting a pref) would probably be ideal, although I haven't done much Thunderbird stuff for a while so couldn't say exactly what the behavior should be...

Revision history for this message
In , Bugzillc (bugzillc) wrote :

Thanks for the add-on so far. I'm continuing to use it with Thunderbird 60 for an indeterminate time to come. Newer versions of Thunderbird broke too many things and took away too many features I regularly use, so that's not for me anymore.

Revision history for this message
In , Rdiezmail-mozilla (rdiezmail-mozilla) wrote :

I wanted to mention that other users like me would like to see this annoying behaviour fixed.

Revision history for this message
In , Jake9wi (jake9wi) wrote :

(In reply to R. Diez from comment #71)
> I wanted to mention that other users like me would like to see this annoying behaviour fixed.

Seconded

Revision history for this message
In , Alta88-t (alta88-t) wrote :

This feature has been implemented in the new (v78) Select Messages column; unchecking it will permanently prevent any auto selection in the folder. It is pretty much this patch, except the reviewers in Bug 1017904 didn't not get it. Note that using ctrl-click to unselect will continue to NOT work, the message must be unselected in the column checkbox.

Changed in thunderbird:
status: Confirmed → Invalid
Revision history for this message
In , Jake9wi (jake9wi) wrote :

(In reply to alta88 from comment #73)
> This feature has been implemented in the new (v78) Select Messages column; unchecking it will permanently prevent any auto selection in the folder. It is pretty much this patch, except the reviewers in Bug 1017904 didn't not get it. Note that using ctrl-click to unselect will continue to NOT work, the message must be unselected in the column checkbox.

Where is this setting located?

Revision history for this message
In , Bugzillc (bugzillc) wrote :

So what if I don't want to use checkbox selection? Is this issue a WONTFIX then?

Revision history for this message
In , Jporter+bmo (jporter+bmo) wrote :

(In reply to alta88 from comment #73)
> This feature has been implemented in the new (v78) Select Messages column; unchecking it will permanently prevent any auto selection in the folder. It is pretty much this patch, except the reviewers in Bug 1017904 didn't not get it. Note that using ctrl-click to unselect will continue to NOT work, the message must be unselected in the column checkbox.

Just to be sure I understand here, you're saying that if I have a message selected, ctrl-click to deselect it, and then delete that message from the context menu, the next message should be selected? I tried doing this on a nightly build and the next message *isn't* selected, so maybe I'm misinterpreting this...

Revision history for this message
In , Bugzillc (bugzillc) wrote :

I'm pressing the Delete key on my keyboard. This doesn't allow deselecting the message before. It doesn't even allow deselecting a message. Why so complicated? Delete that thing and it's gone. I never said to select something else. When I enter a folder, there's no message selected, too! A message has to be selected then, and only then, when I select it.

Revision history for this message
In , Rdiezmail-mozilla (rdiezmail-mozilla) wrote :

I second that request. A "Select Messages" column sounds the wrong way. I cannot easily test it though, because my Linux distribution has not upgraded to version 78 yet.

I am also finding alta88's behaviour, closing as WORKSFORME, more annoying than the bug itself. This bug has been here for 10 years, has had duplicate bugs. Other e-mail clients behave better in this respect. Abruptly closing the bug like that is not the way to go.

Revision history for this message
In , Alta88-t (alta88-t) wrote :

(In reply to Jim Porter (:squib) from comment #76)
> (In reply to alta88 from comment #73)
> > This feature has been implemented in the new (v78) Select Messages column; unchecking it will permanently prevent any auto selection in the folder. It is pretty much this patch, except the reviewers in Bug 1017904 didn't not get it. Note that using ctrl-click to unselect will continue to NOT work, the message must be unselected in the column checkbox.
>
> Just to be sure I understand here, you're saying that if I have a message selected, ctrl-click to deselect it, and then delete that message from the context menu, the next message should be selected? I tried doing this on a nightly build and the next message *isn't* selected, so maybe I'm misinterpreting this...

If you ctrl-click to deselect a message, then context menu delete either that message or another message, a message will be selected, on 78 and linux, for me.

Clearly the best way is to ctrl-click deselect permanently, but the incomprehensible and unusable feedback here has resulted in it being accomplished another way.

Changed in thunderbird (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Changed in thunderbird:
status: Invalid → Confirmed
Revision history for this message
In , Bazuchan (bazuchan) wrote :
Revision history for this message
In , Bugzilla2007 (bugzilla2007) wrote :

*** Bug 1585532 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Bugzilla2007 (bugzilla2007) wrote :

*** Bug 1681092 has been marked as a duplicate of this bug. ***

Revision history for this message
In , L@u (laurent-roche) wrote :

I've forked Alexey addon to be able to select previous message on delete :
https://addons.thunderbird.net/fr/thunderbird/addon/select-prev-on-delete/

Revision history for this message
In , Adomingo (adomingo) wrote :

I would suggest to add an option to deselect emails when you delete one in: "Preferences -> General -> Read and visualization"

Changed in thunderbird:
importance: Medium → Unknown
Revision history for this message
In , Q-joshua (q-joshua) wrote :

Please address this issue. I'm using the "mark as deleted" setting. Pressing the delete key in the message list toggles the "deleted" flag of the selected message as desired, but it also annoyingly selects the next message in the list. When I'm editing a message by changing its flags, I don't want my mail client to automatically select another message. The current message should simply stay selected. The "Deselect on Delete" addon doesn't solve my use case, because it deselects on delete instead of keeping the selection.

Revision history for this message
In , Pierre Ossman (Cendio AB) (ossman) wrote :

The new overhaul of Thunderbird unfortunately broke the workaround addon again. :/

I don't suppose anyone has had time to look at implementing this in Thunderbird directly?

Revision history for this message
In , L@u (laurent-roche) wrote :

I've updated my addon and it now works with Thunderbird 115, it has not been validated ... but hopefully soon.
https://addons.thunderbird.net/fr/thunderbird/addon/select-prev-on-delete/

Revision history for this message
In , Pierre Ossman (Cendio AB) (ossman) wrote :

Great. :)

Unfortunately, in my case I'm a user of the deselect addon, so that's what I was referring to. I don't know if that developer is following this bug?

Revision history for this message
In , L@u (laurent-roche) wrote :

Strange : the latest version (3.6 published August, 8th) of " Deselect on Delete TB78" (unfortunate that the name includes "TB78") should work with Thunderbird 115.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.