86930 - Status Bar biff doesn't clear at times.

Status: VERIFIED DUPLICATE of bug 84705

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Suresh]

I've seen this few times. Whenever I receive new msgs, after I read them all or
select that folder to acknowledge it, the Account level biff clears, NOT the
Status bar biff.  Note the I don't see this all the time but I've seen this few
times. And I showed this once to Sheela also.

Build: Today's build on Win NT.

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

I've seen this too.  

Comment 2

[Nick Lewycky]

I see this regularly and repeatedly.
After reading my messages, the biff doesn't disappear until the next
biff-mail-check, but the green arrow is gone from the Mail Folders selection.
Interestingly enough, openening a new window has the biff set to the correct
(unset) state. There shouldn't ever be some mozilla windows showing different
biff state in the component-bar.

Also, I experience this on Linux, so perhaps the OS should be set to all.

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

os/plat=all

Comment 4

[Eric Vaandering (no email)]

Seeing this on 0.9.3 (linux). It doesn't seem to be clearing with an automatic
check either. Only when I "Get Msg"

Wasn't a similar problem fixed in bug 68879 not too long ago? 

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

Actually, bug 68879 wasn't truly fixed to my knowledge, I think there is some
leak or something that is keeping it from being such.  But, Suresh did a really
good job in making it better ;-)

Comment 6

[Grégoire Colbert]

Check out
mozilla/source/mailnews/base/src/nsStatusBarBiffManager.cpp#101

In function at line 101
nsStatusBarBiffManager::PerformStatusBarBiff(PRUint32 newBiffFlag)
we have a conditionnal test from line 110 to line 156 which handles the sound
alert (it beeps or play a sound).

At line 163, another conditionnal block to line 197. This one seems to handle
the UI update (status bar and folder) of all the windows. I guess the bug is
between lines 179 to 192...

Hmmm, not sure though... I think I need to give my idea about this. Basically, a
procedure sets the green arrow. You click on it, retrieve your mail, which
unsets the arrow. This is fine. Though, at the end of the retrieval, the arrow
reappears and is set again. A possible explanation is that the set/unset of the
arrow seems to be dependant of its previous state (a kind of boolean, something
like newstate = invert(oldstate)). Since there is one redundant call to set the
Biff flag during the actual retrieval of the mail, the arrow remains green until
the next time you press the "Get mail" button, where the first call removes it.

I hope someone will understand this, but chances are that this is where the bug
comes from...

Comment 7

[Suresh]

COLBERT, your comments makes sense. I'm still trying to find a consistent
reproducable testcase, so that we can confirm that!! 

Comment 8

[Nick Lewycky]

I can't seem to repro this with .96 any longer, the biff gets unset when I go to
read the unread message.

Comment 9

[Sheela Ravindran]

Suresh,
Any luck with this on the recent builds?

Comment 10

[Suresh]

I've seen this in recent builds. I'm not able to duplicate this consistently tgh. 

Comment 11

[Sheela Ravindran]

Marking this as a dup of bug 84705

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

Comment 12

[Sheela Ravindran]

verified as dup