Bugzilla

Short summary of comment 90:

This bug seeks to improve the functionality of the *manual* attachment reminder, aka [Remind me later]: independent of magic words in body, and independent of current number of attachments.
Like an alarm clock, the resulting behaviour should be straightforward, predictable, safe, and simple (ON or OFF).

1) We can safely assume that users who deliberately click [Remind me later] from notification or menu actually WANT to be reminded (to prevent them from forgetting to add one or more attachments)

2) As bwinton says, given that we don't know how many and which attachments they want to be reminded about, we should not secretely switch off the reminder automatically just because any one more attachment was added.

3) Instead, before sending, we should just remind those users via alert anyway, per bwinton's guiding verdict (see comment 78):
> Don't remove the check unless manually unchecked, because we have no way of telling what the user
> meant when they checked the box, and guessing wrong is going to annoy them a lot.

4) As mkmelin says (comment 88), behaviour needs to be consistent for [Remind me later] from notification bar OR menu option. So we need to stop guessing for [Remind me later] from notification bar, too, and just show the alert at send time (without looking at attachments added).

5) As an exception to "TB should never deactivate the manual reminder", we do need an exit condition for the manual reminder *after* showing the alert, to avoid users getting into an alert loop. When user dismisses the alert (via "Oh, I did" or [x]/[ESC]), we can assume the manual reminder job done, hence deactivate it at that point (or just send the message if requested via [No, Send now]). (That's even consistent with notification bar behaviour where after dismissing it via [x] you will not get alerted upon sending).

5) For users who just ignore the word-based notification bar, we are not changing the behaviour; conditions for showing the /unrequested/ "aggressive" alert have not changed (you'll only see that if the notification bar is still visible when sending, which implies: no attachments, magic words in body, and notfication not dismissed).

Short summary of comment 90:

This bug seeks to improve the functionality of the *manual* attachment reminder, aka [Remind me later]: independent of magic words in body, and independent of current number of attachments.
Like an alarm clock, the resulting behaviour should be straightforward, predictable, safe, and simple (ON or OFF).

1) We can safely assume that users who deliberately click [Remind me later] from notification or menu actually WANT to be reminded (to prevent them from forgetting to add one or more attachments)

2) As bwinton says, given that we don't know how many and which attachments they want to be reminded about, we should not secretely switch off the reminder automatically just because any one more attachment was added.

3) Instead, before sending, we should just remind those users via alert anyway, per bwinton's guiding verdict (see comment 78):
> Don't remove the check unless manually unchecked, because we have no way of telling what the user
> meant when they checked the box, and guessing wrong is going to annoy them a lot.

4) As mkmelin says (comment 88), behaviour needs to be consistent for [Remind me later] from notification bar OR menu option. So we need to stop guessing for [Remind me later] from notification bar, too, and just show the alert at send time (without looking at attachments added).

5) As an exception to "TB should never deactivate the manual reminder", we do need an exit condition for the manual reminder *after* showing the alert, to avoid users getting into an alert loop. When user dismisses the alert (via "Oh, I did" or [x]/[ESC]), we can assume the manual reminder job done, hence deactivate it at that point (or just send the message if requested via [No, Send now]). (That's even consistent with notification bar behaviour where after dismissing it via [x] you will not get alerted upon sending).

6) For users who just ignore the word-based notification bar, we are not changing the behaviour; conditions for showing the /unrequested/ "aggressive" alert have not changed (you'll only see that if the notification bar is still visible when sending, which implies: no attachments, magic words in body, and notfication not dismissed).