GNOME Bugzilla – Bug 731535
Composer state not restored when resuming the draft
Last modified: 2021-07-05 13:24:30 UTC
When we start composing a message, several bits of information get stored in the composer: the state of the composer (inline, compact, new), the email addresses for a simple reply, the email addresses for a reply all, whether the recipeints have been changed by hand. This state is not restored when the draft is saved and then reopened. The most noticeable problem is that it reopens in the INLINE_NEW mode, even if it's supposed to be part of a conversation. We're assuming that this combination is not allowed, so this will lead to odd behavior. I see two ways to fix this: 1) We can store this information with the draft, perhaps in a custom header, so we can restore it on load. 2) We can try to fake it as best we can: We can set the mode to be new or inline based on whether it refers to another email. We can look at that other email to see what the recipients would be and whether they've been modified. (Or we can just assume they've been modified). The former would be the slickest experience, but it means a fair amount of work across several levels of the code. The latter would be fairly easy, I think.
Can you list all the pertinent state that needs to be saved (if we went with option 1)? It occurs to me that we have two ways to save state: in the headers, as you noted, as well as with flags. I'm inclined to go the second route -- path of least resistance -- but am curious about how much state we're talking about.
Looking through the recent commits, I think these are the bits of state that we might want to store: ComposerState state ComposeType compose_type Gee.List<Geary.Attachment>? pending_attachments string reply_to_addresses string reply_cc_addresses string reply_subject string forward_subject string reply_message_id bool (to_entry.modified || cc_entry.modified || bcc_entry.modified) Note that pending_attachments, the addresses, the subjects, and reply_message_id could be recreated from the original email. We could safely guess that the recipients are unmodified in the COMPACT state and modified in the INLINE state, or we could compare them to what's expected. Also, I don't know if we need to save the state -- we could always restore in an appropriate state, regardless of where it had last been. (If we open drafts automatically, we'll have to avoid the detached mode anyway.) We can try to guess the type from the subject line, but that'd be a bit more fiddly. My worry here is what to do when we can't find the original email. (Suppose it was deleted.) We could make conservative choices for everything, but there's no way around the fact that we'd need two code paths. If we saved the info, we wouldn't have this worry. I note that everything except pending_attachments could be easily serialized and deserialized as needed. And I don't think anyone would be too upset if the pending attachments were lost during the draft save/restore cycle.
(In reply to Robert Schroll from comment #0) > When we start composing a message, several bits of information get stored in > the composer: the state of the composer (inline, compact, new), the email > addresses for a simple reply, the email addresses for a reply all, whether > the recipeints have been changed by hand. This state is not restored when > the draft is saved and then reopened. The most noticeable problem is that > it reopens in the INLINE_NEW mode, even if it's supposed to be part of a > conversation. This reminds me of bug 730486, which should probably depend on this bug.
I think it is important to be able to return to the same conversation view when re-opening a draft. Given that Geary doesn't allow multiple compose messags to be active at once, this missing feature makes saving a draft a regrettable action -- you can't get back to a view where you have the original message and the conversation view both on screen at the same time. If the re-loaded draft loses data about changes to the outgoing email addresses that's a major bug -- often we compose a draft and edit/change the reply list. It would be very annoying to accidentally send an email to unintended recipients as a result of save-draft/reload/send, which seems to be suggested above. Regarding the reply message -- don't you have to send an In-Reply-To: header in the outgoing message? Can't that be saved as part of the draft message? https://www.ietf.org/rfc/rfc2822.txt
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/geary/-/issues/ Thank you for your understanding and your help.