Open Bug 246865 Opened 20 years ago Updated 18 days ago

Support timer delayed sending of message (msgs to go via outbox)

Categories

(Thunderbird :: Message Compose Window, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: alecf, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: parity-Outlook, Whiteboard: [workaround:comment 22])

User Story

https://support.mozilla.org/en-US/questions/1055687
https://support.mozilla.org/en-US/questions/1204459
https://support.mozilla.org/en-US/questions/1234629
So here's something that outlook does, that I hated at first but have grown to
like. Outlook has this concept of an Outbok where ALL messages go to be sent.
That means when you send a message, the mail isn't sent immediately, but rather
the next time Biff goes off.

At first I hated this because my mail didn't go out right away. Then I noticed
that it actually sends is fairly regularly.. it doesn't look like its attached
to biff after all, as it sends more quickly than that. And frankly, I stopped
noticing that this was happening after about a week or 2 of using outlook for
some pretty time-critical stuff.

What's the advantage here? When I compose a message and sent it, it appears to
send immediately.. there's no waiting for the server to be contacted, blah blah
blah.. the message is packaged up, and the compose window just closes. Even if I
do a 5 meg attachment, the compose window just closes! It improves my mail
experience because I don't wait for the message to be sent, and it makes the
mail client seem faster.

Now you still have to handle error conditions, and indicate to the user that the
message hasn't been sent. Outlook does an ok job at this, by marking the Outbox
as having unread messages (thus turning the folder bold) - I could also imagine
a status bar icon or message like "Messages waiting to be sent" that you could
click to either send the messages now, or at least give some kind of status as
to when they will be sent.

We already have some of this capability with the "Unsent Messages" folder (a
better name than "Outbox" too, IMHO) so what we really need is:
- a preference to turn this on, so that all messages are "Sent Later"
- a timer that goes off every xx minutes/seconds whenever there are messages in
the Unsent Messages folder (lets call this send-biff)

Other issues that might come of this:
- when the user is using Unsent Messages the way it is now, do we send those
messages automatically too? (i.e. normally it asks at startup "Send unsent
messages now?" - if the user says no, and then sends a message, do we send the
messages that the user decided not to send earlier? Do we distinguish between them?)
- How does the current mechanism to send unsent messages relay errors to the
user? What do we tell the user about a message that they thought had gone out?
THis probably isnt' a problem as long as we tell the user QUICKLY - which means
making send-biff happen quickly.
bart decrem has an extensions which adds this support which you can use (the
outbox extension)
(In reply to comment #1)
> bart decrem has an extensions which adds this support which you can use (the
> outbox extension)

I downloaded Bart Decrem's extension from here:
   http://outbox.mozdev.org/
but it didn't work for me in Thunderbird 1.0 on Windows.

However, this extension from Chuonthis/BatBat did:
   http://extensions.geckozone.org/Outbox
The documentation is in French but the "Send Later" button it adds is in English.
there is an additional point to this, outlined in
https://bugzilla.mozilla.org/show_bug.cgi?id=284240:

I'll abbreviate: you're using multiple mailservers to send your mail (say gmail,
yahoo and your isp). One of those mailservers is suddenly down. With the outbox
/ unsent mail functionality as described in this bug, when sending fails, your
message stays in the outbox (and you should get a notification of the failure).
When the timer expires, Thunderbird tries to resend, etc. Eventually, it'll
succeed, or you close Thunderbird. When you do, the email is preserved (not the
case right now unless you save it to unsent items.. which you might not want to
do.. if you want to send it directly, it should go to the outbox/unsent and from
there be sent immediately (send delay timer = 0).. so you won't have to manually
trigger sending of the outbox/unsent items.

Now, the current functionality of the unsent items would be hampered by this
change.. but it could be used as a sort of drafts folder (concept used in many
other email clients.. drafts holds emails that you don't want to send but still
store).

I'd also like to point out that the current Outbox extension does by no means
cover the outbox functionality known from other email clients (as outlined by
Alec and now myself, and this is really a showstoper for many possible
convertees from other mail clients (mostly people using Microsoft clients which
unfortunately is pretty much the default client in the Windows world). 
*** Bug 301365 has been marked as a duplicate of this bug. ***
Does the MagicSLR plugin (http://extensionroom.mozdev.org/more-info/magicslr)
meet all of the needs stated here, including multiple account support?
As a convert to Thunderbird from Outlook about six months ago, this is the one feature I still pine for.  The key is not "send later" (as the extensions seem to deal with) but with the automatic delayed sending of messages (auto-save into Unsent Folder, auto-send every xx minutes).  

Besides being able to batch-send your messages, another great use is for those last-second thoughts of "oh, I forgot to mention x" or "I should have stated that differently" or "oops, I forgot to add the attachment", etc.  There have been many times with Outlook where this 5 minute delay feature "saved me" from an error (although, I suppose, this could just be a bug request relating to my brain :) -- or just gave me a minute to reflect on something I just "sent" before actually sending.

I see that the 1.5 beta deals with "Auto Save as Draft for Email Composition" (http://www.mozilla.org/products/thunderbird/releases/1.5beta2.html) -- but it doesn't mention anything regarding the delayed send feature (as a business user, not a tech user, I haven't been able to test this).

Anyway -- for what it is worth -- this was the biggest hiccup I faced when switching to Thunderbird from Outlook and still remains the thing that bothers me most.
would forcing the message compose window to background while sending (until, if, an error occurs) achieve the desired affect?
Severity: normal → enhancement
OS: Windows XP → All
Hardware: PC → All
Summary: Delayed sending of messages → Support delayed sending of message
Version: unspecified → Trunk
QA Contact: message-compose
This feature would expand the userbase. 
Flags: blocking-thunderbird3?
Is this a blocker for bug 122519? 
not a blocker for tb3
Assignee: mscott → nobody
Flags: wanted-thunderbird3?
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Shame - this is the one feature that is stopping me, and several others I have spoken to, from switching to TB.
Summary: Support delayed sending of message → Support delayed sending of message (msgs to go via outbox)
marking wanted+
Flags: wanted-thunderbird3? → wanted-thunderbird3+
(In reply to comment #7)
> would forcing the message compose window to background while sending (until,
> if, an error occurs) achieve the desired affect?

There are different purposes for the Outbox, and I think it would kill a few birds with one stone.

Personally I object to having the Compose window stuck on the screen waiting for a message to send, and I object to how sending out multiple messages at once (more personal that way) opens lots of concurrent connections to the server. I consider that impolite and would much prefer that they're all gracefully queued in the Outbox and delivered one by one in turn (one connection per SMTP server only).

In my case, minimising the window would be a workaround for the nuisance of the Compose window sitting there doing nothing, and it would give the program a much more responsive feel, like with other mail clients. It won't solve the queue issue though.

Personally I am a little divided on a safety delay with sending -- it's a great idea but I'm too used to the idea that something just sends immediately and arrives immediately without anyone having to wait. Since the delay will likely be configurable, I'd just set it to zero.

Too bad this won't be fixed for Thunderbird 3 :(
(In reply to comment #13)
> Personally I am a little divided on a safety delay with sending -- it's a great
> idea but I'm too used to the idea that something just sends immediately and
> arrives immediately without anyone having to wait. Since the delay will likely
> be configurable, I'd just set it to zero.

I come from the opposite camp.  I am too used to the idea of mail NOT being sent until I actually decide to 'post' it (in my case, automatic sending of mail is completely turned off).  It is very common that I need to check over a mail having written it, clicked on send, and then remembered some last bit of information I meant to add, or someone else I meant to copy in, or a file I forgot to attach, or that I sent it from the wrong account, or etc. etc.  

This is a serious issue, and it is the ONLY thing which is stopping me from switching to Thunderbird.  I personally don't see what the objections against this (to me) vital feature are.

I can understand if the situation is that no-one has got round to coding it - that is a shame, but understandable on an open-source project.  Is that the case, or are there technical or idealogical reasons why this has not been implemented yet?
I'll vote for this, and note that a similar enhancement is requested in Penelope Bug 398008 (Eudora had a single "Outbox", where messages were "Queued" and sent when configured in "Preferences").
Comment 0 looks like the send in backgrounf that standard8 is working on we should dup that bug to the send in background.
My request comes from a bit different - I sometimes regret sending something a second after it was sent (or thinking of a better way to phrase, another idea to add, etc.). A default delay (configurable) for all sends would have allowed me to cancel the send (even by abruptly pulling the network cable - that's fine). 
It seems other clients indeed have this feature.
(In reply to comment #18)
> http://getsatisfaction.com/mozilla_messaging/topics/where_did_the_send_button_go_on_e_mails_i_compose?topic_tools=open

Matt, you want to add [gs] to whiteboard, paste http://gsfn.us/t/1cczn into the bugzilla URL field. Do you have access to "get short url" in getsatisfaction, and whiteboard and URL field in bugzilla?
Whiteboard: [gs]
So, another 6 months goes by, and once again I return to Thunderbird with the hope that I can finally migrate away from Outlook.  Nope.  Still can't.  Until this feature is implemented, I'm stuck, as the dangers associated with 'instant send' are too great.

Based on anecdotal evidence, I am not alone in finding this issue a show-stopper in migrating to TB - a large number of people I have spoken to about it think the same.  If I were running the project, I would give serious thought to making this bug a high-priority issue (unless you don't really care about winning people away from MS, that is...)
Mark -- I've figured out a tangle of add-ons that allows this to work.

For me, the highest priority by far in Thunderbird is getting the two text editors to actually work. It's murder trying to get Thunderbird to *****STOP***** sending out HTML mail as "Variable Width" (you'll get something annoying like Times New Roman) and I get people complaining why my mail has come through in huge writing, or the font changes randomly (I don't know what it keeps doing with the font size). The plain text editor is also terrible -- long ago I uploaded a screenshot of what Mac Outlook Express 5 gave you back in 1999 (quote colour levels IN the composer, dynamically adjusted as you type, and block quote/strip quoting -- it made plain text message editing really viable).

I can't recommend Thunderbird so long as the plain text AND HTML editors remain truly dreadful, and so many times, I've wanted to be able to recommend it, but ultimately couldn't as I have so much trouble with it. The positive side is that, with add-ons, I still retain more control than I do over, say, Windows Live Mail, although that is getting really good now (far better program than when it was still Outlook Express or even Windows Mail).

Thunderbird is a write-off, it's dragging along going nowhere, incrementing its major version number without seeing any changes worthy of that. It's tragic really.
Seems to me that some combination of sendInBackground (core Thunderbird functionality), the BlunderDelay add-on and the Send Later add-on satisfy all the functionality requested in this bug, with the exception of the rant about the editor in comment 21, which was totally off-topic and shouldn't have been posted here.

In short, I think this bug should be closed as resolved.
It's managable with BlunderDelay and MagicSLR, but not a beautiful solution. It is really important functionality for many people (including me) and I keep not understanding why this isn't in the core of TB (but instead the chat functionality appeared out of nowhere).

I still think it's desirable to have this as core TB functionality, instead of having to mess around with two addons.
This is essentially bug 511079 - background send - which is not yet implemented
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Whiteboard: [gs] → [workaround:comment 22][gs]
(In reply to Herre de Jonge from comment #23)
> I still think it's desirable to have this as core TB functionality, instead
> of having to mess around with two addons.

I agree.  I assumed the reason this bug wasn't moving was because of core architectural issues that made it impossible, but if the result can be achieved via addons, this is clearly not the case.

I therefore can't see any technological nor idealogical reason not to include this in core, nor does it seem very hard to implement if there are working implementations already available in the addon ecosystem.

FWIW, this is still the blocker that stops me from using TB.
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #24)
> This is essentially bug 511079 - background send - which is not yet
> implemented
> 
> *** This bug has been marked as a duplicate of bug 511079 ***

This is not a duplicate of that bug, though it may be dependent on it.

Bug 511079 is about freeing up the user-interface so that the send happens in the background.  It still causes the e-mail to be sent 'immediately' from the point of view of the user (it is just that 'immediately' is actually 'delayed by a second or so' in practice).

This bug is about adding a preference to allow a specified period of delay before a message is sent (e.g. 30 minutes) or to disable automatic sending altogether (requiring the user to manually send/receive).

I agree the bug subject makes them appear similar, but the proposal in comment 0 includes the additional detail that makes this into a different (but related) issue.
Coment 0 made it sound like this only concerned a Biff on a fixed schedule, which therefore mean a message would be delayed anywhere 1 and N seconds.  But in 
- https://support.office.com/en-za/article/Delay-or-schedule-sending-email-messages-253dbfd7-0db7-4f41-bcc5-9e8e68ae29bf 
- http://blogs.msdn.com/b/edkatibah/archive/2012/12/17/setting-up-a-delayed-sending-rule-for-email-in-microsoft-outlook.aspx
it sounds like what outlook has is a fixed delay per message. 

In that case, this should be rolled into bug 122519
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #27)
> it sounds like what outlook has is a fixed delay per message. 
> 
> In that case, this should be rolled into bug 122519
> 
> *** This bug has been marked as a duplicate of bug 122519 ***

I'm not quite sure if it's a duplicate of that bug either.

Bug 122519 is about adding an alternative sending option - 'send scheduled' - that can be used on a per-message basis as an alternative to 'send (immediately)'.

This ticket is about adding a global setting that affects all messages (or, presumably, if that bug is implemented, then all messages except those with an explicit schedule set), which allows you to add a fixed delay before messages go out or to disable automatic sending completely.

Again, this bug may be dependent on 122519, but I don't think it is the same thing.

It is important to note that this bug can't simply be resolved by automatically populating the scheduling fields when the user clicks send.  This is firstly because there needs to be an option to not send automatically at all (only when the user triggers a manual send/receive) and secondly because there should be a prompt when closing the application that 'there are unsent messages - do you want to send them now?' which would not work if they were explicitly scheduled for half-an-hour's time.
Thunderbird already has send later.  Ctrl+Shift+Return  There is even an add-on for the toolbar icon if that is to hard.  The toolbar buttons add-on calls it send and receive. (sounds just like outlook really)
Thanks. I have clarified the bug summary
Status: RESOLVED → REOPENED
Depends on: sendinbackground
Resolution: DUPLICATE → ---
See Also: → 122519
Summary: Support delayed sending of message (msgs to go via outbox) → Support timer delayed sending of message (msgs to go via outbox)
Status: REOPENED → NEW
Blocks: 1251440
User Story: (updated)
See Also: → 242079
Whiteboard: [workaround:comment 22][gs] → [workaround:comment 22][parity:outlook]
Severity: normal → S3
Keywords: parity-Outlook
Whiteboard: [workaround:comment 22][parity:outlook] → [workaround:comment 22]
You need to log in before you can comment on or make changes to this bug.