After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743970 - Don't ask to discard an empty new e-mail
Don't ask to discard an empty new e-mail
Status: RESOLVED FIXED
Product: geary
Classification: Other
Component: ux
0.9.x
Other Linux
: Normal normal
: 0.12.0
Assigned To: Geary Maintainers
Geary Maintainers
Depends on: geary-wk2
Blocks:
 
 
Reported: 2015-02-04 09:18 UTC by Age Bosma (IRC: Forage)
Modified: 2017-01-31 23:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Age Bosma (IRC: Forage) 2015-02-04 09:18:54 UTC
Picture the following:
- Click on the "Compose new message" button
- Do not fill in any field. I.e. leave To, Cc, Subject and e-mail body empty
- Click the close/discard button

I've always wondered why e-mail clients (in particular) think it would be essential to ask for a confirmation now. Why am I being asked to cancel or discard the e-mail?
All is empty so it's nothing yet. It's not as if I can't reproduce the same nothing by pressing the "Compose new message" button again.
If the user decides otherwise it can start a new e-mail again through a more familiar path (compose button) than through a dialog.

Since Yorba is all about reconsidering things to improve: please reconsider this behaviour as well ;-)
Let Geary be an e-mail client that does not ask redundant questions. An empty e-mail can be discarded without questions.
Comment 1 Robert Schroll 2015-02-04 21:13:27 UTC
The reason Geary asks this is because it's easier to always ask than it is to figure out when not to ask :).  That's not a *good* reason, and this has irritated me too.

We need to consider that there are more routes leading to this dialog than just the close button.  Choosing a conversation or starting a search will trigger the composer to consider closing itself.  In these cases it's less obvious that the user meant to close the open composer.  Should we still close without a dialog?  (Probably, in my opinion.)  What about replies or forwards?

I seem to recall that we were having problems detecting whether or not the message had been modified in some cases.  I don't remember the details or if it's been fixed.  Jim, does this ring a bell.

We've also been considering getting rid of this dialog in all cases, and relying on drafts to let you return to compositions seamlessly.  We're making progress on that front, so it may not be worth fixing this particular instance if all of the dialogs are going away soon.
Comment 2 Age Bosma (IRC: Forage) 2015-02-04 21:30:24 UTC
Good to hear that at least some form of change is being considered.

I'd say the same goes for unaltered replies and forwards when the dialog remains.

If it makes it any easier: I'd vote for leaving the e-mail address fields out of consideration all together. So even if an input field like To or Cc has been filled/altered in case of a new e-mail, reply or forward then no dialog should be presented when the message is being discarded either. No harm is done when loosing that information if you ask me.
A purist might disagree with that view though.
Comment 3 Jim Nelson 2015-02-04 22:56:27 UTC
Relevant bugs here are bug #712926 and bug #726290.  The core issue here is that we rely on WebKit's undo facility to know when a message has been edited.  (This is also used to know when to save drafts.)

I would *think* we could rely on the scheme drafts use to know when changes have not been saved (ignoring bug #726290 for a moment) to ask about discarding a new message.

Ultimately, what bug #712926 is suggesting is that we find a more appropriate way of determining when changes are made.  That would seem to apply here too.
Comment 4 Michael Gratton 2017-01-14 12:56:27 UTC
The WK2 port no longer relies on the undo state to determine whether the message body has been modified. It's actually more conservative, hence it's probably safe to fix this issue, so I have fixed this on that branch.
Comment 5 Michael Gratton 2017-01-31 23:43:05 UTC
Fixed on master with commit 29b339c.