Open Bug 505604 Opened 15 years ago Updated 2 years ago

Deleting the last read message opens the previous message

Categories

(Thunderbird :: Message Reader UI, defect)

Product:
Thunderbird
Component:
Message Reader UI
Platform:
x86
Windows XP
Type:
defect

Tracking

(blocking-thunderbird3.1 -)

Tracking Flags:
Tracking Status
blocking-thunderbird3.1 --- -

People

(Reporter: rocktman3, Assigned: Bienvenu)

References

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Lightning/1.0pre Thunderbird/3.0b3

After reading the last msg, I delete it. TB then automatically opens the previous msg in the message pane. Makes no difference what the sort order is: ascending date or descending date.

In Options/Reading & Display, I have "Close message window on delete" checked. Also selected is "Open message in: An existing message window."

Reproducible: Always

Steps to Reproduce:
1.Open & read last msg in msg window
2.Delete msg
3.
Actual Results:  
Previous msg opens

Expected Results:  
When I delete the last msg, no more msg windows should open. I should have no msg windows open.
Confirmed here on

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2pre) Gecko/20090721 Lightning/1.0pre Shredder/3.0b4pre ID:20090721034342
Status: UNCONFIRMED → NEW
Component: Folder and Message Lists → Message Reader UI
Ever confirmed: true
QA Contact: folders-message-lists → message-reader
Whiteboard: [STR comment #0]
I'm not sure if this is a regression. I remember that this feature was ok in the past, but I'm not sure.

Ludovic it happens also on Mac?
Wayne you remember if this is a regression?
I'd say this sounds like a dupe of bug 498141.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
I agree.
Whiteboard: [STR comment #0]
Status: RESOLVED → VERIFIED
Reopening, since 498141 doesn't fix this.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
I installed TB 3.0 RC1 yesterday & the short test I gave it this morning (about 5 msgs), leads me to believe it's resolved. So now it's WFM.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → DUPLICATE
The fix for bug 498141 did not fix this; it still happens in 3.0rc1 on Mac OS X. Also note that this is definitely a regression from 2.0.0.23.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → UNCONFIRMED
Ever confirmed: false
Are you using group by sort?

Sometimes my last message has multiple message indicated for the thread (I use group by sort in all my folders), and if I delete the selected message neither the next message nor the previous message gets open. Not reproducible on demand as far as I can tell.

It would help a great deal if you/someone would track down the exact regression range http://garykwong.wordpress.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/
Keywords: qawanted, regression, regressionwindow-wanted
(In reply to comment #9)
> Are you using group by sort?

No. Sorted by date, unthreaded.
OK, bisection done. It actually went through a different but equally incorrect behaviour in the middle. 2009-06-12-02-comm-1.9.1 is the last build that behaves like 2.0.0.x, while 2009-06-13-02 leaves the message window open showing the deleted message. 2009-06-23-02 is the first build that exhibits the current behaviour.
checkins on 6-22 include
 Bug 498344 -  navigation (e.g., next unread) doesn't work in stand-alone msg window
 Bug 499064 -  need way for pending listener to know when a db has been opened

my guess is 498344. hurrah for regression hunting (and Joshua)!
Keywords: regressionwindow-wanted
Blocks: 498344
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #12)
> checkins on 6-22 include
>  Bug 498344 -  navigation (e.g., next unread) doesn't work in stand-alone msg
> window
>  Bug 499064 -  need way for pending listener to know when a db has been opened
> 
> my guess is 498344. hurrah for regression hunting (and Joshua)!

QA's job seems done. :)
Flags: blocking-thunderbird3.1?
Keywords: qawanted
Version: unspecified → Trunk
I wonder if there isn't other fallout from bug 498344, besides this bug. 
(I lost my train of thought over the last few days, so maybe will add more later)
Since this was apparently caused by bienvenu's fix, I'm going to give him the first shot at fixing it!

I _think_ this probably wouldn't block 3.1 if it were the last bug standing, in large part because (I'm guessing) it requires two non-default preference settings as per comment zero, which means that it's unlikely to effect a high percentage of users (someone should chime in here and renominate if that's wrong).

That said, having found the regression date here may make this significantly easier to fix (thanks, Joshua & Wayne).
Assignee: nobody → bienvenu
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1?
How is this a regression? If I'm understanding correctly,  we've always done this. If delete doesn't close the msg window, it loads the next available message, just like we would if there were a thread pane visible.
(In reply to comment #15)
> I _think_ this probably wouldn't block 3.1 if it were the last bug standing, in
> large part because (I'm guessing) it requires two non-default preference
> settings as per comment zero, which means that it's unlikely to effect a high
> percentage of users (someone should chime in here and renominate if that's
> wrong).

I should probably have mentioned that I'm seeing this with different settings to those mentioned in comment 0. In fact I don't see the problem with "Close message window on delete" checked.

I have "Close message window on delete" unchecked, and have selected  "Open message in: A new message window."

The behaviour of delete in 2.x with these settings is to open the next *unread* message, or to close the window if there are no unread messages. This is what regressed.
Are you viewing unread messages only? Because a normal view all messages view would not behave the way you describe, in 2.0 or 3.0, afaik.
I tested with an inbox which contained a mix of read and unread messages. Testing consists of double-clicking the first unread message and then deleting until the last unread message has become read and then deleted. I did confirm the behaviour in the older builds mentioned in comment 11 as well as 2.0.0.23.
We really don't prefer unread vs read messages when figuring out what message to load next. It all depends on the sort order. Are you sorted/threaded the same way in both tests?
Yes, the mailbox ordering is the same in all my testing. You're right about it not caring whether messages are read or unread, what changed is that deleting the last message in the list used to not open the previous message. It just happened that I virtually always had all unread messages grouped together at the bottom since I sort by date.
Ah, ok, thx. Are you saying that deleting the last message used to close the entire message window?
(In reply to comment #22)
> Ah, ok, thx. Are you saying that deleting the last message used to close the
> entire message window?

Yes.
Deleting messages displayed in tabs does not work homogenously.
1. If this is the rightmost tab then the behaviour is as stated above.
2. If the tab is somwhere in between other message tabs the message stays displayed no matter how many times one hit delete though the actual message is deleted.
I'd rather have that message tab closed and focus transfered to the first tab on the left if in existence or just folder tab view displayed if not. Same applies to the first situation.
(In reply to comment #22)
> Ah, ok, thx. Are you saying that deleting the last message used to close the
> entire message window?

I agree: in TB2 deleting the last message in a sorted list (while reading) closed the message window, signaling to me that I had deleted the last message. (This was usually, though not necessarily, the last new message in the list).

In TB3 (including 3.1.2) deleting the last message in a sorted list (while reading in a tab) selects the preceding (the new last) message in the list. If I continue deleting I will eventually delete all messages in the mailbox.

My rationale: I have many mailboxes into which new messages are automatically filtered, adding to the existing messages. I typically start reading midway through the sorted list, beginning with the new messages, and for each message I delete or skip as appropriate. When I get to the end of the list (again, typically, but not necessarily, the last new message) I want the message tab to close, as it did in TB2, as a signal that I've dealt with all new messages. I don't want to be presented with the preceding messages that I may now accidentally delete.
PLEASE differenciate between two situations:
1. Every message viewed in a separate window.
2. Messages viewed in tabs.
If viewed in tabs see my previous comment because the behaviour is not the same.
I also had a problem with "close message window on delete" while using tabbed messages. I had to switch from opening messages in tabs to opening in new windows because my preference is to close a window when deleting a message rather than opening the next message in the same window, and that's the only way I could get that to work. Glad you are working on it. Thanks.
What is the progress on this? I've been very unhappy with this behavior for years now. Deleting the last message in a folder from a message window should close the message window, not display the previous message.
I see there is no comment on this for over 2 years, but it still behaves this way. I am using the current release of Thunderbird on Windows 7 Enterprise 64-bit. What is the status on this?
This behavior still persists, and it continues to vex me on a daily basis.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.