Go to next unread message ignores folders with one unread message

RESOLVED FIXED

Status

SeaMonkey
MailNews: Message Display
RESOLVED FIXED
15 years ago
14 years ago

People

(Reporter: Barry Stone, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

({fixed1.4.2, fixed1.5})

Trunk
x86
Linux
fixed1.4.2, fixed1.5

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210

Using the Go To Next Unread Message command in any method ignores local or POP
folders that have only one unread message.  You must select those folders
manually and issue Next Unread to see them.

This problem doesn't happen with IMAP folders

Reproducible: Always

Steps to Reproduce:
1.Mark a message in a totally read local or POP folder as unread
2. Select another folder
3. Press 'n'

Actual Results:  
After reading all other unread messages, you never go to the marked unread message.

Expected Results:  
Shown you the marked unread message

Comment 1

15 years ago
Confirming for 1.3 Final, 1.4b
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030408

To fine tune the report:  Have two POP accounts, two user folders in Local
Folders, and at least one subscribed newsgroup.  Set up the 2nd POP account so
there is only one unread message in it; set up the user folders so that there
is only one unread message; set up the newsgroup so there are unread messages.

Go to the first POP account, enter the Inbox, select 'n': both the second Inbox
and the Local Folders will be skipped over, in favor of the newsgroup.

If each Local Folder has one unread message each, 'n' from the first Inbox will
skip the second Inbox, but stops at the unread message in the first Local
Folder.  Selecting 'n' again from here will skip the second Local Folder to
go to the newsgroup.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

15 years ago
Same here for news. 
If the last folder is a news folder and there is only one unread message. 
N for next unread doesn't work.

Comment 3

15 years ago
*** Bug 188271 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Flags: blocking1.4+

Comment 4

15 years ago
only Mozilla drivers can set (+) blocking flags.  you can request (?) the
blocking flag.
Flags: blocking1.4+

Comment 5

15 years ago
Sorry,
i think this is a blocker for 1.4.
I my Dayly newsreading there is at last a news-group with only one mail in it.
N for next message is not working.

Anyone of the cc think thas this is a blocker?
What is Seth Spitzer thinking?

Thanks

Comment 6

15 years ago
I have the following:

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529

Definitely the same behavior here.  I agree this is a blocker, needs to be fixed.

Comment 7

15 years ago
An additional behavior I have noticed with this bug.  This only occurs with
messages that are moved into folders via message filters, so it will find a
single unread message in the Inbox. It will not find the unread message in
another folder if the Inbox is selected, but if I select the folder containing
the message, or a parent folder that contains a sub-folder that contains the
unread message, then it goes to that message properly.  Otherwise, if Inbox
selected, it attempts to go to  the next unread message in the next Account,
skipping the unread message in the current account that is in another folder. 

Comment 8

15 years ago
Strictly speaking it's a dup, but who cares?
Depends on: 126626

Comment 9

15 years ago
bug 126626 is fixed, whats now?
Go to next unread message ignores folders with one unread message still exists.
Guenter

Comment 10

15 years ago
I just installed thunderbird and i wonder this is working fine in
mail and news. Why not in mozilla mail and news? Has m scott a fix for this problem?

Comment 11

15 years ago
I think the priority on this very annoying bug should be increased.  If you use
filters to distribute messages to various folders, a no-find from next unread
requires that you manually scroll through the list of folders to see whether
there is one final unread message.  I subscribe to several busy list serves and
filter the messages from each list into a separate folder.  Messages dribble in
all day long so every few minutes I have to go hunting to see whether one last
unread message is hiding is some folder.  It is as nagging as water torture.

This bug prevents me from recommending any version of Mozilla higher than 1.3,
the last version in which next unread found all unread messages, to friends and
family.  Since 1.5RC1 was just released, I hope this bug can be fixed in 1.6.

Comment 12

15 years ago
Created attachment 131747 [details] [diff] [review]
Fix type of variable

Bah, I compared it to 0 without realizing that it erroneously was unsigned :-(
Of course the variable was declared correctly in GetTotalMessages...

Comment 13

15 years ago
Comment on attachment 131747 [details] [diff] [review]
Fix type of variable

Matches the type used in GetTotalMessages.
Attachment #131747 - Flags: superreview?(bienvenu)
Attachment #131747 - Flags: review?(bienvenu)

Comment 14

15 years ago
Comment on attachment 131747 [details] [diff] [review]
Fix type of variable

the change is the right thing to do, but does it really fix the problem?
Attachment #131747 - Flags: superreview?(bienvenu)
Attachment #131747 - Flags: superreview+
Attachment #131747 - Flags: review?(bienvenu)
Attachment #131747 - Flags: review+

Comment 15

15 years ago
Comment on attachment 131747 [details] [diff] [review]
Fix type of variable

Seeking any approval going - this is a simple fix for an obvious bug.
Attachment #131747 - Flags: approval1.5?
Attachment #131747 - Flags: approval1.4.2?

Comment 16

15 years ago
Comment on attachment 131747 [details] [diff] [review]
Fix type of variable

a=asa (on behalf of drivers) for checkin to the Mozilla 1.5 branch. Please add
the fixed1.5 keyword when this is landed on the branch. Thanks.
Attachment #131747 - Flags: approval1.5? → approval1.5+

Updated

15 years ago
Keywords: fixed1.5

Comment 17

15 years ago
Did this ever land on the trunk? Does it need to?
Flags: blocking1.6b?

Comment 18

15 years ago
Asa: It seems that neil%parkwaycc.co.uk has landed this on 2003-09-19, see
nsMsgFolder.cpp rev 299.

So this is probably only left open for 1.4.2.

Comment 19

15 years ago
Thanks Robert. I didn't look close enough and was thrown off by the typo in the
checkin comment that referred to this bug as 210392 rather than 201392.
Unsetting blocking 1.6b request. 
Flags: blocking1.6b?

Comment 20

15 years ago
Comment on attachment 131747 [details] [diff] [review]
Fix type of variable

a=mkaply for 1.4.2
Attachment #131747 - Flags: approval1.4.2? → approval1.4.2+

Comment 21

15 years ago
Fix checked in to the 1.4 branch.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Keywords: fixed1.4.2
Resolution: --- → FIXED

Comment 22

15 years ago
*** Bug 216341 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.