Remove unnecessary Warning when changing Identity

[AlbertHain]

While changing sending-identity with "Identity Chooser" I receive the warning "Thunderbird reports, you already typed something. Load template nevertheless …"
This is of course intended, it's not a bug, it's THE feature of SmartTemplates. So there is no need to warn.

[RealRaven2000]

Thanks for reporting. I believe it may be identity chooser setting the "dirty flag" in the editor - hence the warning "Thunderbird reported you typed something". If we can somehow detect and reset that we will try. otherwise we can configure suppression of the warning (but then it won't warn you if you start editing and then change the template and potentially lose everything you have typed after the previous template loaded).

We might also force a save to drafts before changing the template?

[AlbertHain]

tried without "identity-chooser". Indeed it seems to be the editor who sets the dirty flag. I did'nt find an option to suppress this warning in the extended settings for that. So it seems, I have to live with that.
Saving drafts to user-defined default folder (i.e. trash ;-) ) would be a good solution, but I think this would be to much work for that small issue. In any case there would be an alert box to be clicked. :-(,

[AlbertHain]

see above - don't spend to much time on that issue. Thanks for your quick reaction ;-)

[RealRaven2000]

OK. I checked, even when we change the identity in Thunderbird itself, (by using the "from" dropdown, without identity-chooser) then Thunderbird sets:

gMsgCompose.bodyModified = true

so the behavior is also triggered then. I would be interesting whether there is a way to guard against this. We would have to store something in the body of the email or wrap bodyModified somehow.

[RealRaven2000]

I tried patching a version of identity chooser, here in its background script. Problem is that the call to

await browser.compose.setComposeDetails(tab.id, details);

will still force isModified = true (even if we explicitly add isModified:false as part of the details).

we can then overwrite isModified with a dedicated call to

browser.compose.setComposeDetails(tab.id, {isModified:false});

but at that stage it is to late - Thunderbird hardcoded setting isModified = true as soon as the identity is changed. We should ask Thunderbird to try and retain the isModified flag in this case because of potential side effects like this.

API Documentation for setComposeDetails

My attempt to patch identity chooser was :

let chosenIdentity = await this.popupPrompt(identityWindow.id, null);

 if(chosenIdentity == null || chosenIdentity == "cancel") {
   browser.windows.remove(composeWindow.id);
 } else if(chosenIdentity != null) {
   let originalDetails = await browser.compose.getComposeDetails(tab.id);
   const details = {
     identityId: chosenIdentity,
   };
   const isBackupUnModified = (originalDetails.isModified === false)
   if (isBackupUnModified) {
     details.isModified = false;
   }
   await browser.compose.setComposeDetails(tab.id, details);
   if (isBackupUnModified) {
     const afterDetails = await browser.compose.getComposeDetails(tab.id);
     if (afterDetails.isModified === true) {
       browser.compose.setComposeDetails(tab.id, {isModified:false});
       console.log("Restored isModified to false after setting identityId");
     }
   }
 }
}

[RealRaven2000]

We might still turn this one into something productive - by adding a request to,the web extension team, asking why they set the isModified flag and whether it can be suppressed by passing false in the passed details structure.

[RealRaven2000]

Can you check

bugzilla.mozilla.org/show_bug.cgi?id=2014004

and please add a comment? Apparently another Add-on author specifically requested the modified flag to be set when the from is changed in Tb 115 - I think that is an antipattern, it's really bad.

Original request for this change was here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1850192

[AlbertHain]

seems to be closed …

the discussion is - in my mind - not from the view of the customer (ease of use) but from the perspective of an axiom (never loose data). The solution in this sense is: force the user to first change his identity and then answer - this is educating the user. One solution would be to implement a switch "ignore dirty flag if identiy changes" in the extended options.
Thanks for your effort Axel, my life still goes on without this feature ;-)

[RealRaven2000]

The bug is closed - not the discussion. But yet you need either a Bugzilla / Mozilla or Github account to log on to Bugzilla to participate in any discussions

[AlbertHain]

I tried with the github-account - did'nt work

[RealRaven2000]

It's ok, I cam up with a workaround. Reopening this issue (I will close this myself later, when I decide to add it to SmartTemplates official). I now store a hash of the <div id=smartTemplate4-template> contents which contains the "editable body" of the email. I recheck the hash when the identity is changed. if it is exactly the same, I ignore bodyModified and do not ask the question. Works nicely with identity picker, as well.

Here is a test version:

smartTemplate-fx-4.18.1pre26.zip

To test the version above, download the zip file, drag the file into Thunderbird Add-ons Manager, do not extract contents or if won't install.