Open Bug 1767092 Opened 3 years ago Updated 3 years ago

should not have save dialog when closing composition window which is "empty" and unedited, but switched identities

Categories

(Thunderbird :: Message Compose Window, defect)

Thunderbird 100
Unspecified
All
defect

Tracking

(Not tracked)

People

(Reporter: wsmwk, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #1740102 +++

Steps to reproduce:

  1. configure two accounts with signatures
  2. open compose with identity 1
  3. close window - not prompted
  4. open compose with identity 1
  5. switch to identity 2
  6. close compose window

prompted with discard, cancel or save

Apparently the change in signature triggers an indicator that the body has changed.
There is a code path that is not resolved by bug 1740102?

Tbh, I would consider this expected behaviour, and I don't think this poses any problem in real life.
Changing sender is changing the message. Changing sender may also change your Auto-CC/BCC/Reply-To etc. - definitely changes of message. If you open a new Word document and change just a single space - it'll prompt you to save.

What is the real-world use case of starting a new composition, changing sender, and then closing it again? Haven't you started it and changed the sender because you really wanted to write to somebody? I would want to be reminded about that unfinished message, because I have started it for a reason, which I'll probably remember.

Even if we'd agree to ignore the user's manual change of sender, that can only apply for a brand-new message which is totally empty (no body, no subject, etc.). As soon as the message has any content, changing the sender must definitely count as change of message, and ignoring that may easily violate user's privacy. Message may have been manually user-saved (or auto-saved?) just before user decides to changes sender. So technically, change of sender may be the only current change. If we discard that w/o asking, when user restarts the same draft, change of sender is unexpectedly lost, which can easily violate sender's privacy.

I think the answer to this "issue" is easy - don't change your message properties if you don't want to be asked about those changes...

I also recall that we have discussed this elsewhere already, and arrived at the conclusion that the cases where we could possibly discard the sender change (and other similar changes) are so narrow that it's not worth creating exceptions and code checks for them, and it would confuse more than it helps. Having change of sender sometimes alter the message (as soon as there is any other content, required behaviour per my comment1) and sometimes not (when message is "empty") is arguably inconsistent.

Summary: should not have save dialog when closing composition window which is "empty" and uneditted, but switched identities → should not have save dialog when closing composition window which is "empty" and unedited, but switched identities

Tbh, I would consider this expected behaviour, and I don't think this poses any problem in real life.

Not hardly. I have over 12 accounts, six of which I use frequently. So I have a one in six chance than I'm in the account in which I want to compose. And in the 5/6 chance that I'm not, I start compose and then in compose I change to the desired account. I should expect from that point that the compose window behaves exactly as if I had started compose with that account.

In 91.8.1 (Windows) that has nothing to do with switching identities. I click "Write", and then I immediately close the composition window (Alt-F4 or click top right X). I do not type or click anything else, which means I also do not change "From". That's when I get the Save/Discard changes/Cancel dialog, but only if "Compose Messages in HTML Format" in Account Settings -> Composition & Adressing is not ticked.

(In reply to Otto PETER from comment #4)

In 91.8.1 (Windows) ... if "Compose Messages in HTML Format" in Account Settings -> Composition & Adressing is not ticked.

That is your bug 1740102 which is fixed in beta, but not fixed in version 91.

You need to log in before you can comment on or make changes to this bug.