Menu Item - Inbox Count Bug
 

I've been beta testing for three weeks now, and have noticed this bug in every release. Figured now is a good time to report it. :-)

In the menu item's menu, the inbox's overdue (red) items number does not show a consistent number. When I repeatedly click the menu item, the inbox number changes through 1, 6, 0, 6, 3, 7, 3, 0, 1, 3, 1, 1, 6, 6, 3, 1, 3, 7.

The correct number is 1, which should have displayed every time.

Anyone else experiencing this bug?

[URL="http://homepage.mac.com/markmillard/FileSharing9.html"]See the movie.[/URL]

I don't use the menu bar icon, but I turned it on to test this issue. And I think you're right. I see some strange behavior with the gray Inbox count. Like your example, if I click the menu item repeatedly, the count goes haywire and eventually disappears.

Have you logged this with OG (select Help->Send Feedback...)?

Good idea. Done.

This bug is still there. OF developers, any hope in getting it fixed before the 1.0 release?

Yeah, I noticed this the other day as well. Would be nice to have it fixed as it behaves a bit wacky right now.

Please give this a try in 96446 or later. I've added a silly little hack that seems to avoid this problem (at least I can reliably reproduce it w/o the hack and not with it). This seems to be a bug in Mac OS X -- pretty funky.

This OF menu item has escaped my attention. Can't see a reference to it in Preferences - how does one activate it ?

RobTrew: You can activate the menu bar item with a checkbox under Preferences->Data->Dates & Times.

Tim Wood: It's definitely better, but I can still produce some strange behavior by hiding the OF window, opening and closing a different Menu Extra (the iChat icon, in this case), then opening the OF menu item. The count value is missing for my Inbox and the indention seems off.

Tim, in 96450 your fix looks good for my basic use case. However, Toadling is on to something. If I select another menu item (like the standard sync item), then return to the OF menu item, the problem is still there.

Ken was able to still reproduce this too; I've added a better workaround in r96476.