Closed Bug 531534 Opened 15 years ago Closed 14 years ago

"Close message window on delete" does not work when messages are opened in tabs

Categories

(Thunderbird :: Toolbars and Tabs, defect)

x86_64
All
defect
Not set
normal

Tracking

(blocking-thunderbird3.1 -)

RESOLVED FIXED
Thunderbird 3.3a2
Tracking Status
blocking-thunderbird3.1 --- -

People

(Reporter: dmbfan36, Assigned: squib)

References

()

Details

(Keywords: regression, Whiteboard: [gs][ NO comments about the extension please ])

Attachments

(2 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0

I have "Open messages in: A new tab", and I checked "Close message window on delete" (mail.close_message_window.on_delete is set to true).  If I delete a message that's opened in a tab, the tab does not close, it loads the next message.

Reproducible: Always

Steps to Reproduce:
1. Make sure Thunderbird is set to open messages in tabs and to close message windows on delete
2. Double-click a message in a message list so that it opens in a new tab
3. In the message tab view, click the delete button
Actual Results:  
The next message in the folder list loads in the current tab

Expected Results:  
The tab closes
I'm seeing this as well on Windows XP with Thunderbird 3.0 RC1. Always reproducible and I'm working with an IMAP folder.
Flags: blocking-thunderbird3?
Not blocking on this. The preference does explicitly say window and not just message, although it is a bit confusing being just below the open preference.

We're not going to hold TB 3 for this, especially as we can't alter strings, but we'll consider it in 3.1.
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3.1?
Flags: blocking-thunderbird3-
Can we make a "Close Message Tabs on delete/move" option in 3.1?
I have the same problem but I've noticed slightly different behaviour. 

1. After a restart of Thunderbird, I opened 3 messages in tabs.
2. I read the message in the rightmost tab and deleted it using the delete button on the tab - the tab automatically closed.
3. I then read the message in the new rightmost tab and deleted it using the delete button on the tab, but the tab stayed open and the buttons in the message header disappeared.
4.I closed the tab manually and read the message in new rightmost tab and deleted it using the delete button on the tab. The tab then displayed the next message in the folder, and the buttons did not disappear.
Confirmed on Thunderbird 3.0 on OSX Snow Leopard.  I'd love a preference (even if just a hidden one) for closing tabs on delete as per comment #3 in 3.0.1 or as soon as possible.

Oh, and I don't experience Alistair's situation, the tabs don't close on deletion regardless of how many tabs I have open.

Thanks
Hi,
on
http://antone.geckotribe.com/alpha-gecko/transition-from-mailapp-to-thunderbird-custom-compiled/
somebody described to fix this issue in TB2:

Well, the transition took a little more work than expected, but I’m now happily running my own custom version of Thunderbird, secure in the knowledge that if I don’t like the way it works, I can always change it. For anyone who may want the close-window-on-delete behavior, and doesn’t mind compling their own app, here’s the necessary code change: in mozilla/mail/base/content/messageWindow.js, change this (at line 210):

if (gNextMessageViewIndexAfterDelete != nsMsgViewIndex_None)

to this:

if ((!gPrefBranch.getBoolPref(’mail.close_message_window.on_delete’)) && (gNextMessageViewIndexAfterDelete != nsMsgViewIndex_None))

…and make sure you’ve got that configuration setting set to true.


Not sure if this is working and if it would work in TB3. But it does not look too much of a Problem ?!?

regards

Hermann
Set status to New: I can't find any dupe.
Status: UNCONFIRMED → NEW
Ever confirmed: true
this should be considered a v3 regression
Keywords: regression
OS: Windows 7 → All
Version: unspecified → 3.0
(In reply to comment #10)
> this should be considered a v3 regression

Debatable since we didn't have tabs in v3 and we don't necessarily have to have the same implementation for tabs as we did for windows (I'm not saying that they can't be the same, just indicating why this isn't necessarily a regression).
By default, controlling which message is opened in Thunderbird is “very difficult” to control.  The issue is the way Thunderbird selects the next message after you've delete or move a message; it selects and opens the next unread message, possibly one you DON”T want open.  I’m sure most see this as a feature reducing the number of clicks it takes to read email.  But, by doing so can result in getting more messages; spam.  This is a security issue that exposes countless unaware users and makes spammers very happy.  Thus, this issue needs to be address within Thunderbird and not by add-ons such as “Unselect Message” and “After Delete” which are not function in release 3 and served as patches in earlier version of Tb making them usable for the security minded.

The current selection and opening of, and previewing messages, should be a configurable option; with risk warnings upon selecting to educate users.

The Security Issue Background:

To avoid being tracked by spammers, security minded folks, immediately turn off email client preview modes.  Hopefully in Thunderbird this is successfully accomplished by means of turning off the “Message Pane” (View\Layout\Message Pane).  Many know that spammers like validating (testing) recipients email addresses because those lists bring higher revenue.  Thus they use techniques that trigger upon messages just being viewed by the recipient email client, regardless if the user really read it or not.

So best practices mandate not viewing (reading) any possible spam/junk email.  The only true control for validating a message is by "human review" of sender, subject and possibly reviewing detail message headers (View\Message Source) prior to opening a message.
I agree with the previous post that this should be a configurable option, however I personally expected it to close the message tab and I think such defaulted behavior would satisfy most's expectations.

I differ in opinion however and contend that the current behavior is not a security threat. Since Thunderbird defaults to blocking remote content I think the spam/email-validation issue raised is already mitigated.
Delete failed to close tab or window; epic fail.  The setting should apply to tabs, but even so - as written the text implies it will close a message window.  It does not.  thunderbird-3.0.1-1.fc12.i686

While it's true the security risk is mitigated, I want my new messages to stay new until I'm ready to read them.  They shouldn't automatically load when I delete a message.
I'm glad I found that this bug has already been reported.  I just updated to T-bird 3.0.1 and was surprised when the tab did not close when I deleted the message, even after I chose the option to "close message window on delete".  Yes, it does say "window" and not "tab", but I think the behavior should be the same.  I want full control over when I open a message.  The way it is now, it takes two clicks to delete a message and close a tab, and it should only take one.  Thanks.
I'm hoping that this bug covers (and would fix) - the issues that are preventing
add-ons like “Unselect Message” and “After Delete” from working. I just can't allow TB continue to make the decision to select the next message for me. Please, please provide the "hooks" needed by the developers to enable those add-ons to work correctly again. This single issue is so important for me - that I continue to remain on TB2. If this is a different issue - can someone please advise - and will be happy to open a new bug report.  Thanks and Regards to all, Doug
This problem really bothers me, too, though I can't see any reason to not move from TB2 to TB3 because of it--if you set TB3 to open messages in a new window instead of a new tab, and set it to close window on delete, then you've got the same delete-and-close capabilities you have with TB2, without the need for Unselect Message or After Delete, and with all the other benefits of TB3 except for tabs.  It's just a shame that those of us who hate having the next message brought up automatically on delete (I can't imagine why anyone wouldn't find that a real pain, but whatever) can't enjoy tabs, which seems to me the biggest benefit by far of TB3.  But maybe this is much harder problem to fix than I would have guessed.
My understanding is that this bug is why the add-ons After Delete and Unselect Message do not work. Without those add-on TB, new features and all, is not on my dance card.
There's a corollary to this issue as well - when you open a mail erroneously marked as junk and click on Not Junk, it moves that message to the Inbox and opens the next junk message!  That's the last thing I want is to be opening junk mail.
Because 3.1 is mostly about ensuring that we have something that Tb2 users are willing to upgrade to, I think it doesn't make sense for this to block because of the reasoning described in comment 17.  Adding wanted-thunderbird+, however.
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1? → wanted-thunderbird+
OK, I'm despairing of seeing the desired "close message (tab) on delete" (return to message list) and reluctantly using the provided functionality, but even if I DID learn to love "delete and move to next unseen message", I'd STILL need a "DON'T delete, but move to next unseen message" button.  Please consider this when addressing this issue.  Thanks - Peter Buck
#22 Peter Buck - you mean like N for next unread message?

(BTW, in TB 3.0.3 on Fedora 12, this bug is still not resolved.)
I also find this behavior very frustrating.  I want messages to stay unread until I want to read them.  I am new to Thunderbird.  I installed it to back up my Gmail account since gears is going away and was giving me some problems.  I was most impressed at how TB set up and synced to my Gmail account, but this behavior is making me think about going back to the Gmail web client.
Puhleeze fix this!  A tab is a window differing only in context.  I'm still on Mail.app 90% of the time due to this infuriating bug.
A MILLION THANKS!!!
Somehow, without asking, I got a nightly build of TB when I booted up this evening: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5.  In this version clicking on the X on a message tab deletes the message and returns me to Inbox view.  Just what I expect!  As far as I am concerned, this but is fixed. - Peter Buck
(In reply to comment #27)
> A MILLION THANKS!!!
> Somehow, without asking, I got a nightly build of TB when I booted up this
> evening: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10)
> Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5.  In this version clicking on
> the X on a message tab deletes the message and returns me to Inbox view.  Just
> what I expect!  As far as I am concerned, this but is fixed. - Peter Buck

SORRY, I WAS WRONG!!  "Delete" still displays next message instead of returning to the Inbox listing.  The "x" on the tab closes the message (doesn't delete it) and returns to the Inbox listing.  No change.  Forget what I said. Bug is still there.
Oh no I had hoped so much for this issue to be fixed with TB 3.1 :(   I can't understand how anyone can NOT be bothered by the open next message behavior after deleting (when using tabs).
I subscribe to this 100%! I can't understand how anyone can NOT be bothered by the open next message behavior after deleting (when using tabs). Please make the addons "After Delete" or "Unselect message" work again. This auto-selecting behavior without any chance to alter it sucks big time!
Whiteboard: [gs]
This bug is following a very typical tbird pattern of old, useful behaviour breaking with the introduction of a new version, followed by ABSOLUTELY NO ACTION BY THE MOZILLA FOUNDATION.  I hope it doesn't take over 10 years (and counting) to fix like some of the bugs accumulating in Tbird.  One of those bugs meant a wholesale conversion of my lawyer clients from tbird to outlook when netscape suite passed on (OLD)!

My recommendation -- live with it, dump it, or find a way to poke someone at the foundation.  I'm pretty sure none of the developers are paying much attention to bugzilla.

Anyway, here's my confirmation:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100826 Thunderbird/3.0.7

I have the messages opening in a separate message window and I'd like the window to close when I delete the message, NOT open the next message.
(In reply to comment #31)
> I have the messages opening in a separate message window and I'd like the
> window to close when I delete the message, NOT open the next message.

This "Close message window on delete" _does_ work when messages are opened "in a new window".  This bug report is for the case where messages are opened in a new tab; the "Close message window on delete" does NOT close the tab when the message is deleted.
(In reply to comment #32)
> (In reply to comment #31)
> > I have the messages opening in a separate message window and I'd like the
> > window to close when I delete the message, NOT open the next message.
> 
> This "Close message window on delete" _does_ work when messages are opened "in
> a new window".

Comment 31 was very clearly worded.  The feature DOES NOT work with a message opened in a new window.
(In reply to comment #33)
> Comment 31 was very clearly worded.  The feature DOES NOT work with a message
> opened in a new window.

WFM.  The only case I can reproduce on Thunderbird 3.0.6 is when messages are open in a tab.  Messages opened in a window are closed when deleted as expected.
(In reply to comment #31)
> Anyway, here's my confirmation:
> Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100826
> Thunderbird/3.0.7
> 
> I have the messages opening in a separate message window and I'd like the
> window to close when I delete the message, NOT open the next message.

Can you please double verify that the preference 'close message window on delete' under 'Advanced' -> 'Reading & Display' is checked?


(In reply to comment #33)
> Comment 31 was very clearly worded.  The feature DOES NOT work with a message
> opened in a new window.

If your preference (mentioned above) is checked, then it would be helpful to know your environment and version.

Window behavior is working fine for me, tab behavior is not.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

chris
(In reply to comment #35)
> Can you please double verify that the preference 'close message window on
> delete' under 'Advanced' -> 'Reading & Display' is checked?

It is checked.  I even unchecked and re-checked (which I do every couple releases.)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Thunderbird/3.1.3
'Close window on delete option' should be changed to 'close window or tab on delete'.  

Once I delete a message, I want to return to an overview of all the messages, rather than constantly be presented with the next message in this folder. Surely this is the point of including the option in the Settings.  

It does not work if the messages open in a tab.  It does if they open in a window.  I am therefore changing my preferences to open messages in a window, which rather negates the much-trumpeted 'improvement' offered by v3 of using tabs.

This seems to be a very old bug.  Do any developers read this section or is it just a place for users to vent?
Still doesn't close window on delete for me.  As usual with an upgrade, I disabled the feature then enabled it again.  Testing in new window and tab; both loaded the next message on delete instead of closing the window (or tab).

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc13 Thunderbird/3.1.6
Still doesn't work in any of the 3 message view modes (new tab, new window, existing window).  Every way, it still displays the next message instead of closing and returning to the list of messages.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101103
Fedora/1.0-0.33.b2pre.fc13 Thunderbird/3.1.6
I can't believe this bug still exists after over a year. I have found an extension that fixes this behavior at http://www.flamber.dk/thunderbird/ctod/
Does what it says on the tin. No tests yet.
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED
Comment on attachment 502627 [details] [diff] [review]
Make tabs close when messages are deleted

:asuth, what do you think of this strategy? I'm vaguely aware that there's a MessageDisplayWidget which might be a better place to put this handling, but I'm not sure that's necessary.
Attachment #502627 - Flags: feedback?(bugmail)
Comment on attachment 502627 [details] [diff] [review]
Make tabs close when messages are deleted

Thank you for pursuing a fix for this bug!

The close handling should go on the MessageDisplayWidget (sub)classes as you try and rationalize not doing ;).  They vary with the tab type (folder tab: MessagePaneDisplayWidget, message tab: MessageTabDisplayWidget, message window: StandaloneMessageDisplayWidget) while FolderDisplayWidget only varies with the window type (3-pane: FolderDisplayWidget, message window: StandaloneFolderDisplayWidget).  While I grant that FolderDisplayWidget already does poke around inside _tabInfo a little bit, I think it's cleaner to defer to the varying implementation, especially since your proposed change would add a degree of hard-coding that is not currently present in our accesses of _tabInfo.

I think a name like "maybeCloseDisplay" or "closeDisplayIfMessage" or something like that might be more appropriate.

Really, the big thing for a fix for this bug is test coverage...
Attachment #502627 - Flags: feedback?(bugmail) → feedback-
(In reply to comment #40)
> I can't believe this bug still exists after over a year. I have found an
> extension that fixes this behavior at http://www.flamber.dk/thunderbird/ctod/

Just installed this on 3.1.7 and it works! Great work and THANKS!
Now that there is a fix, maybe this bug can be fixed for good in an upcoming release?!
its not fixing the "open next message"-behavior after deleting. Still, the next message gets auto-selected.
How's this, :asuth? Still no tests yet. That comes tomorrow (probably).
Attachment #502627 - Attachment is obsolete: true
Attachment #502677 - Flags: feedback?(bugmail)
Comment on attachment 502677 [details] [diff] [review]
Move logic to MessageDisplayWidget

Looks good!  Do you have push access to our try server?
Attachment #502677 - Flags: feedback?(bugmail) → feedback+
(In reply to comment #47)
> Comment on attachment 502677 [details] [diff] [review]
> Move logic to MessageDisplayWidget
> 
> Looks good!  Do you have push access to our try server?

I do not. Do you want to push this to the try server?
Attached patch Now with tests (obsolete) — Splinter Review
Here are some tests for the patch. Hopefully they're sufficient, since I just modeled them after the window-based versions of the tests.
Attachment #502677 - Attachment is obsolete: true
Attachment #502865 - Flags: review?(bugmail)
Comment on attachment 502865 [details] [diff] [review]
Now with tests

>+  onMessagesRemoved: function MessageTabDisplayWidget_onMessagesRemoved() {
>+    if (this.folderDisplay.treeSelection.count == 0 &&
>+        pref.getBoolPref("mail.close_message_window.on_delete")) {
>+      document.getElementById("tabmail").closeTab(this.folderDisplay._tabInfo);
>+      return true;
>+    }

If you're re-using that preference, I think you might want to additionally change the wording of the preference window (advanced / reading & display) because that doesn't mention tabs at the moment.
Ok, this updates the string in the prefs window.
Attachment #502865 - Attachment is obsolete: true
Attachment #502890 - Flags: review?(bugmail)
Attachment #502865 - Flags: review?(bugmail)
Attached image What it looks like
Here's what the new string looks like.
Attachment #502892 - Flags: ui-review?(clarkbw)
Hi Guys,
I've tried this patch, and it seems to fix about 80% of cases.
However, it doesn't seem to address "Move to..." - this reverts back to the old behaviour.
Is it a small enough tweak to add in?

Best regards,
Simon
(In reply to comment #53)
> I've tried this patch, and it seems to fix about 80% of cases.
> However, it doesn't seem to address "Move to..." - this reverts back to the old
> behaviour.

This works for me with the patch. Can you provide more details?
Er, wait... are you referring to my patch here or the extension in comment 44? Because the two are implemented totally differently, and looking at the code for the extension, I wouldn't be surprised if it didn't work when you move a message (it just hooks into the "delete" commands). However, with my patch, it definitely does what you'd expect when you move a message.
ahhh, gotcha!  Yes, I was refering to the extension... sorry!

How can I get an install of your working patch?
I can't see for looking  ;-)

Suffice to say, we are all desperate for this!!

Cheers
(In reply to comment #56)
> How can I get an install of your working patch?
> I can't see for looking  ;-)

You'll either need to download the source code for Thunderbird, apply my patch with the command "patch" (on Unix-like systems) and compile it yourself[1], or wait until the next release of Thunderbird after this passes review. Once it passes review and gets checked in, Thunderbird nightlies[2] will have it, and since it's a regression, it might get backported to the 3.1 branch so that it'll get released sooner (otherwise, you'd have to wait for Thunderbird 3.3).

There's also a chance that there will be test builds of Thunderbird with this patch, as implied in comment 47.

I couldn't say what the actual schedule for this is in terms of getting it to end users, but I did mention elsewhere that I'd like to get this into 3.3 alpha 2 if nothing else. 3.3a2 should be released early next week. Of course, the standard caveats apply about using an alpha release of software (back up your data!).

[1] https://developer.mozilla.org/en/Simple_Thunderbird_build
[2] http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/
Cheers, much appreciated!
Could someone kindly ping this thread when/if the patch becomes available?
I look forward to giving it a go. 
Keep up the good work!
Regards,
Simon.
Hello,

look comment #40, this link: http://www.flamber.dk/thunderbird/ctod/

It works - so we can delete a mail and this tab will be closed instead opening the next mail. That is what we wanted? For me I get the solution of my problem bzw. of my wishes! Thanks for all comments.

Ralf
Please can we stop commenting about the extension on this bug.

We're actively working on a solution to be included within Thunderbird and comments about the extension are now going to hamper the efforts to get this patch to completion.
Whiteboard: [gs] → [gs][ NO comments about the extension please ]
Comment on attachment 502890 [details] [diff] [review]
Update prefs window

This looks good and the try server is happy with your new tests cases (there are some unrelated intermittent oranges).  I think the new tests should cover most everything and if it turns out they didn't, we can add some more tests cases later :)

Thank you for posting the screenshot of the string change, I expect Bryan will find it very helpful!  I'm going to add the ui-review flag to the patch directly too just so it's clear that this patch can't land until the phrasing gets reviewed.  Once Bryan signs off on it or provides a new string, the patch is good to go.

Thanks again for taking this on!
Attachment #502890 - Flags: ui-review?(clarkbw)
Attachment #502890 - Flags: review?(bugmail)
Attachment #502890 - Flags: review+
Attachment #502892 - Flags: ui-review?(clarkbw) → ui-review+
Comment on attachment 502890 [details] [diff] [review]
Update prefs window

looks good!  Thanks again for the screenshot of the pref window
Attachment #502890 - Flags: ui-review?(clarkbw) → ui-review+
r+ and ui-r+, so checkin-needed time.
Keywords: checkin-needed
Checked in for 3.3a2: http://hg.mozilla.org/comm-central/rev/95805deaae99
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a2
It seems that two similarly related, but slightly different issues were being discussed in this topic. It seems that the primary discussion is related to tabs not closing on "delete". The other problem was regarding the next message being automatically selected upon delete, whether or not the message was opened in a separate tab, which the "Unselect" plugin helped to correct in TB1-TB2. 

Regarding the "Unselect" issue referenced in posts #12-20 and others, I also agree that this should be implemented for many of those reasons stated (i.e. spam security). I don't want a message automatically displaying unless I specifically click on that message. If I delete a spam message, I don't want the next spam message (or any other message) to automatically open. 

As I just upgraded to TB3, I was hoping that this would have already been included in this build. Upon finding that it wasn't, I've spent a lot of time searching for a plugin that would work, but there doesn't seem to be one. Of course, I would rather see this feature built into TB instead of hoping someone would build a plugin for this. Right now, I'm debating on switching back to TB2, although I like some of the new features of TB3... however, the lack of this one feature is enough to give up any other features in the new version.
With this particular bug being marked as resolved and fixed - it seems unlikely that the second half of this problem will ever be addressed (at least by this bug report). I would suggest that if others still feel strongly about the "Unselect"
functionality still not working - that you subscribe and vote for the recently reopened bug 395151 https://bugzilla.mozilla.org/show_bug.cgi?id=395151 - as this might be the only place left - to get any traction on the second half of this issue. 

Regards,

Doug
See Also: → 1656728
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: