1779663 - Tidy up nsMsgFolder.getStringProperty and add methods to remove/existence-test properties

Status: RESOLVED FIXED

(Thunderbird :: General, task)

Description

[Ben Campbell]

Following up from Bug #1778888.

in nsMsgFolder:

• add hasStringProperty() for existence check
• add removeStringProperty()
• document getStringProperty in idl file
• add test coverage of *StringProperty() methods

in nsMsgFolderCacheElement:

• numeric accessors to return 0 for actual null values in folderCache.json (to bring them in line with getCachedString())
• return NS_ERROR_NOT_AVAILABLE to better indicate missing entries (rather than NS_ERROR_FAILURE)
• unit test to cover returning zero/"" for null entries in folderCache.json.
• numeric accessors should return 0 when reading string values?

Comment 1

[Ben Campbell]

Attachment: Bug 1779663 - Tighten up folder string properties and their caching. r=mkmelin

For nsIMsgFolder.(get|set)StringProperty methods:

• IDL comments to document them.
• Add basic test coverage.
• Add support for non-latin chars in values.

In nsMsgFolderCacheElement:

• Numeric accessors to return 0 for actual null values in folderCache.json (to bring them in line with getCachedString())
• Return NS_ERROR_NOT_AVAILABLE to better indicate missing entries (rather than NS_ERROR_FAILURE)
• Unit test to cover returning zero/"" for null entries in folderCache.json.

Comment 2

[Ben Campbell]

That patch doesn't add .hasStringProperty() or .removeStringProperty() to nsIMsgFolder, as I originally intended. I decided to avoid these as they'd require new mork code.
If anyone really needs that functionality it be handled in some other bug. In any case, .hasStringProperty() can already be handled via exceptions, and I'm not sure .removeStringProperty() would ever really be used.

I also discovered that get/setStringProperty() would mangle strings with non-latin characters. I changed their IDL definitions to use AUTF8String instead of ACString, which seems to do the trick. Hopefully no addons are relying on the old mangling behaviour :-)

try run looks OK:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=d2a24406623b1be4dd18e779c1dc48f11c374b4e

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/8dcf8970879e
Tighten up folder string properties and their caching. r=mkmelin