1299440 - nsIFolderListener.intPropertyChanged returns wrong pointers

Status: RESOLVED WORKSFORME

(Thunderbird :: Folder and Message Lists, defect)

Description

[Günter]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160811171047

Steps to reproduce:

Setting up a listener to get a pointer to a new added message to a specific folder (e.g. Sent folder). This is using "nsIFolderListener.intPropertyChanged" and should return the proper values with "OnItemIntPropertyChanged: function(aFolder, aProperty, aOldValue, aNewValue)".


Actual results:

"aNewValue" should point the new added message. That works with no message on the folder was deleted or the folder was 'repaired' before using the listener method/callback. 



Expected results:

With an "unrepaired" folder the aNewValue isn't correct and further access to get the message URI / messageHeader 
(e.g. msgUri = messenger.getMsgFolderFromUri({sendFolder}).baseMessageURI + "#"  + aNewValue;)
will fail (throws error or returns wrong message). 
Method to evaluate: use an "unrepaired" folder (one message was deleted, folder was not 'Repaired'). Use "TotalMessages" with the listener. Compare the returned aNewValue with the position of the new message in the folder. Only with a "repaired" folder the value is correct.

Comment 1

[Kent James (:rkent)]

Your description is confusing - did you switch the meaning of Actual and Expected? I don't think that you really expect "With an "unrepaired" folder the aNewValue isn't correct"

I assume the report is that, with a corrupt summary database ("unrepaired" folder), that various methods give incorrect values. I would probably say that the results of most mailnews methods is undefined when the summary database is corrupt, so if I understand the report correctly is is INVALID. Possible valid bugs would be that you expected errors instead of incorrect values, or that you are getting incorrect values but the database reports that it is valid.

But I believe that you have a real problem that I am not understanding.

Comment 2

[Günter]

@Kent
Sorry if the description is "confusing", but what you think "With an "unrepaired" folder the aNewValue isn't correct" is what it does.

FMPOV all it's about working with a folder with one (or more) message(s) has been deleted and with that situation "nsIFolderListener.intPropertyChanged" returns a pointer which doesn't point to the message which was added that very moment and triggered the listener. Maybe this assumption (the return value points to the new message) is wrong, but to what message does it point to? And why not to the new one?

What is the status of a folder with a deleted message? I don't expect it's 'corrupt', I expect it's intact and so the "nsIFolderListener.intPropertyChanged" should work as expected/descrribed ... return the pointer to the 'new' added message. But that's NOT the case. ONLY after using the [Repair Folder] the returned aNewValue points to the new message ... and will work for next calls .. until a message is deleted from the folder.

Comment 3

[Günter]

Please read the first part in Comment 2
Sorry if the description is "confusing", but "With an "unrepaired" folder the aNewValue isn't correct" is what it does.

Comment 4

[Kent James (:rkent)]

"nsIFolderListener.intPropertyChanged" is not where I would expect to get notification of a new message, so I find the expectation "return the pointer to the 'new' added message" confusing.

Integer properties are things like the number of unread messages in a folder, "aNewValue" would be an integer containing the new number of unread messages.

The notification for adding a new message with nsIFolderListener comes through OnItemAdded, which has double use for folders and messages. aItem should contain ansMsgDatabase::AddNewHdrToDB new message added to a folder. It comes from nsMsgDatabase::AddNewHdrToDB

Comment 5

[Kent James (:rkent)]

Sorry,  "aItem should contain the new message added to a folder"

Comment 6

[Günter]

Thanks Kent for pointing to this, will try for that tomorrow and report back. ;)

Comment 7

[Günter]

Using "nsIFolderListener.added" instead of "nsIFolderListener.intPropertyChanged" solves the problem!