A reopened draft is saved over and removed by id through the login and
account it is stamped with, and message ids repeat across servers. Two
ways of opening a draft stamped it with a login that was only on
screen, not the one it was read through:
- A Pro email tab opened by double-click named no login. It read the
message through whatever login the main list was browsing and stamped
the active one: with the 0.16.23 login active and the 1.0 login's
Drafts browsed, the first autosave destroyed the draft's id in the
0.16.23 account and left the draft itself behind. A Pro view now
stamps only a login its host names, and reads the message through
that login's client. A double-click on a row of the mail list or of a
folder tab names the row's login and account, and the search preview
and a folder tab's reading pane name theirs for the active login
too. Without a login the composer goes by the draft's From, as it did
before.
- "Cancel and edit" in Scheduled took the login browsed before, which
stays set while Scheduled lists the active login's mail. The draft
was restored through the active login and then saved over and
discarded through the other one. It now takes the active login, and
a send undone or cancelled for editing never falls back to what is on
screen.
Also:
- A draft version saved through another login is removed only once the
message is out. A host without a connection sent nothing and the
version was removed anyway; it now says so and the draft stays.
- An email tab opened for one login's message no longer focuses the tab
of another login's message with the same id and account.
A draft's old version is removed by id when the composer saves over it,
sends it or discards it. Email ids repeat across accounts and servers -
the same user logged in to two servers is account `e` on both - so the
removal must go to the login and account the draft lives in. Two paths
took the wrong one:
- "Edit draft" in an "All folders" search or a tag view took the account
from the folder still selected underneath. With a group folder
selected, an own draft was opened as the group's, and its first
autosave, send or discard destroyed the message with that id in the
group account, while the draft stayed in the own Drafts. It now takes
the login and account the result is stamped with, reads the draft
through that login, and prefers that login's identity when two
logins share an address.
- The composer discarded through the login of the current From, and
replaced or sent through it too. After switching From to another
login's identity - which saves nothing by itself - discarding,
the next save or the send removed the draft's id on the other server.
Each save now records the login it went through (a draft opened from a
list starts with the list's). A version saved through another login is
removed through that one: after the new version exists when saving,
after the message is out when sending, and on discard.
The Pro email view, folder tabs and search preview pass their login
along with the draft.
Stalwart 1.0 returns every photo, logo and sound in a contact card as a
blobId without a uri, including every photo Bulwark saved as a data:
URI. Bulwark read only `uri`, so avatars, the contact list and detail,
print, vCard export and the "has photo" filter showed nothing, and the
form sent `media` without the photo on every save, so editing a phone
number deleted the photo on the server.
- `ContactMedia` carries `blobId`, `label`, `pref` and `contexts`; `uri`
is optional, and `getContactPhotoRef`/`hasContactPhoto` read both.
- Blob photos are downloaded once each, at most two at a time and at a
paced rate, only while on screen, into an LRU of object URLs revoked
on eviction, account switch and logout. They share Stalwart's
per-account budget of 4 concurrent requests and 1000 a minute.
- Avatars look senders up in an index built once per contact list.
- The form leaves `media` out unless the photo changed, and otherwise
passes the other entries through as the server returned them.
- A new photo is uploaded into the user's own account and sent as a
blobId where the blob capability lists ContactCard (1.0). 0.16 refuses
blobIds in media and keeps getting a data: URI; a refusal at runtime
falls back the same way for the rest of the session.
- Print and vCard export download blob media first; duplicate and
cross-account move send the bytes instead of the source's blobIds.
- vCard export also writes photos whose data: URI names no media type
(`data:;base64,`, `data:base64,`), which it dropped before.
Linus Rath