In-app error notifications

🎯 The objective

Inform the user of errors that occurred while the app was performing foreground or background operations.

A major release feedback item is that emails are not arriving reliably. In part, this is because the app doesn’t always inform the user when an error occurs.

We will use this epic to implement the initial error notifications system, the general error types, and use re-authentication as one example to implement with the new system. Follow-up work in new projects can include implementing further cases such as TLS and other connectivity errors.

🎒 Resources

• https://github.com/thunderbird/thunderbird-android/issues/2000
• https://github.com/thunderbird/thunderbird-android/issues/1058 (not all of this is in scope)
• https://github.com/thunderbird/thunderbird-android/issues/1362
• https://github.com/thunderbird/thunderbird-android/issues/893
• https://github.com/thunderbird/thunderbird-android/issues/3082 (OAuth token failures)
• https://github.com/thunderbird/thunderbird-android/issues/5028
• https://github.com/thunderbird/thunderbird-android/issues/6206
• #3949
• https://github.com/thunderbird/thunderbird-android/issues/6276

🦮 Rules of the Road

🟢 In Scope

• Investigate UX patterns for showing errors or state failures
• Move away from (exclusively) using system notifications
• If there are folder errors, indicate this in the drawer somehow
• Error types:
  • Authentication error
  • Certificate error
  • Sync failures / Connectivity Issues
    • Figure out how prominently to notify the user. When they take an action explicitly (e.g. refresh), then be more on the nose. If syncs happen in the background focus more on “last updated”.
    • Potentially notify for ongoing issues

🔴 Out of Scope

• New UI/UX for dealing with certain errors, e.g. new screen to update credentials after an authentication error
• Bringing up system permission prompts with the new in-app error notification system
• Asking the user to disable battery saver mode

🚧 Technical and/or Business Requirements

• Keep the scope as small as possible so we can quickly ship something that is useful to users.
• Make the in-app error notification mechanism flexible enough so it can be used for addition error types in the future. Examples:
  • Sending a message has failed
  • Uploading a message has failed
  • Marking a message as read has failed
  • Moving a message has failed
  • Deleting a message has failed
  • Fetching the list of folders has failed

Project tasks

Cross-Functional Tasks

🎨 Design

• Develop a design for the new in-app notification area

🤝 Support - Product

• Update SUMO articles to better describe the new error situations