Closed Bug 1653851 Opened 6 years ago Closed 4 years ago

Add ability to store data corresponding to a specific message

Categories

(Thunderbird :: Add-Ons: Extensions API, enhancement)

Product:
Thunderbird
Component:
Add-Ons: Extensions API
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1680608

People

(Reporter: lieser2, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I need to store some data that belongs to a specific message. The data should also be automatically deleted if the message gets deleted.

As the id for a message is currently not persistent (bug 1606573) and there is no listener for message deletion (bug 1627604) it also doesn't seem to be possible for an add-on to implement this easily without an experiment on it's own.

Previously I used the nsIMsgDBHdr.setStringProperty() method do do this.

Personally, even though this was a possibility in the past, I think Thunderbird should not do this for non-standard fields. This is for several reasons:

  • If the add-on goes away, Thunderbird does not know if to remove the deleted data or not (the add-on might not be running straight away).
  • If Thunderbird migrates its storage, it is then the associated add-on data will have to be migrated and supported as well.
  • More generally, Thunderbird developers will have to be aware of this non-standard data and commit to not breaking it. This would never be ideal, as information might not get passed on.

I think we should be fixing the persistent id and message listener issues, and then the add-on can manage its own storage properly.

At least in my use case, I would not need a guarantee that the data will never be deleted, e.g if it is to much work to migrate them. A kind of best-effort to retain them would be good enough. If I remember correctly the data I store with setStringProperty() is also lost then e.g. a folder is repaired via it's settings.
But I could imagine that a best-effort guarantee is not enough for other use cases, so your concerns are valid points.

Fixing the persistent id and message listener would be enough for me too.

The message listeners have been fixed, and there is a bug for the persistent message ID already, so I mark this a duplicate.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.