[ews] Unread count not updating when message is updating read status
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
People
(Reporter: heather, Unassigned)
References
(Blocks 1 open bug)
Details
You can observe a message as being marked as read or unread from the EWS server by:
- mark a message as read in the web UI
- in TB click another folder other than Inbox
- click back to the Inbox and see that the message has changed read/unread status. But the unread count next to the "Inbox" folder has not updated.
- click another folder
- click back to Inbox and see that the unread count has now updated.
You always need to initiate a sync folder messages once more to get the unread count to be true.
Updated•1 year ago
|
Comment 1•1 year ago
|
||
Good catch!
It looks like we're not properly notifying the frontend of the change via NotifyIntPropertyChanged. It looks like most of the other folder implementations use nsMsgDBFolder::ChangeNumPendingUnread (implemented here) to send this notification.
We don't have a good way to solve this with the current shape of the EWS interfaces, because we don't currently have a good way to communicate how many messages have had their unread flags changed in a given update (which is required by both NotifyIntPropertyChanged and ChangeNumPendingUnread). Something to keep in mind when we revisit those interfaces.
We could end all our message list syncs with UpdateSummaryTotals(true) - true here means forcing a database read to get new numbers - but it feels a bit wasteful to me, so I'm not sure about this. NI'ing Ben for his thoughts on this.
Comment 2•1 year ago
|
||
Well, this looks like a nice can of worms :-)
Background:
I don't really know how any of this works, but I've just had a poke about and here are my findings:
The unread count is held on the nsDBFolderInfo object. It's initialised when the folders database is opened, by calling nsIMsgDatabase.syncCounts(). From then on, it's maintained via deltas (i.e. ChangeNumPendingUnread()).
Personally, I think this is overcomplicated and bonkers - what's the point of a database if you can't do simple queries like this?
But I guess it's done like this so that you can have lots of folders, but not have to have the databases open for all of them, because you've got the folderinfo even if the DB is closed..... sigh. The folderinfo is really just a half-arsed cache to work around the silly per-folder database system.
Suggestions:
(caveat: I haven't looked at the EWS side of this)
- I don't think
UpdateSummaryTotals(true)actually does a database query. From looking at the code I think it just uses the folderinfo. So it probably won't help you here, on it's own. - I think calling
SyncCounts()on the database will perform the DB queries you want. And I don't think it'd be expensive, as the database would already be open (and resident in RAM!) if you're performing some operation that affects the count. You might also need to callUpdateSummaryTotals()too? Not sure. - Alternatively, you could call
ChangeNumPendingUnread(1)for each message as it comes. I think there are ways to turn off the notifications during multiple updates, but I'm not even sure you'd even need to do that.
I don't entirely understand the pending count stuff. I think it's a fudge to support IMAP, where the server has told us there are some unread messages, but we haven't yet added them to the database...
My impression of the EWS stuff is that you're being much more direct - "if it's not in the DB it doesn't exist" kind of thing. In which case you might be able to bypass some of these hacks...
Sorry I don't have a proper answer, but I hope there's some useful clues in there!
Comment 3•1 year ago
|
||
(In reply to Heather Ellsworth from comment #0)
You can observe a message as being marked as read or unread from the EWS server by:
- mark a message as read in the web UI
- in TB click another folder other than Inbox
- click back to the Inbox and see that the message has changed read/unread status. But the unread count next to the "Inbox" folder has not updated.
- click another folder
I think this means the inbox database is closed...
- click back to Inbox and see that the unread count has now updated.
... and that this reopens it, thus calling SyncCounts() and correcting the totals.
Description
•