201392 - Go to next unread message ignores folders with one unread message

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Barry Stone]

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

[Mike Cowperthwaite]

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.

Comment 2

[Guenter Huerkamp]

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

[Mike Cowperthwaite]

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

Comment 4

[Andrew Schultz]

only Mozilla drivers can set (+) blocking flags.  you can request (?) the
blocking flag.

Comment 5

[Guenter Huerkamp]

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

[Jim Forsythe]

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

[Jim Forsythe]

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

[[e-mail]]

Strictly speaking it's a dup, but who cares?

Comment 9

[Guenter Huerkamp]

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

Comment 10

[Guenter Huerkamp]

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

[Paul Ward]

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

[[e-mail]]

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

[[e-mail]]

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

Matches the type used in GetTotalMessages.

Comment 14

[David :Bienvenu]

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?

Comment 15

[[e-mail]]

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

Seeking any approval going - this is a simple fix for an obvious bug.

Comment 16

[Asa Dotzler [:asa]]

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.

Comment 17

[Asa Dotzler [:asa]]

Did this ever land on the trunk? Does it need to?

Comment 18

[Robert Pollak]

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

[Asa Dotzler [:asa]]

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. 

Comment 20

[Mike Kaply [:mkaply]]

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

a=mkaply for 1.4.2

Comment 21

[[e-mail]]

Fix checked in to the 1.4 branch.

Comment 22

[Mike Cowperthwaite]

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