[email] Warn user that they are about to discard a new message.

VERIFIED FIXED

Status

Firefox OS
Gaia::E-Mail
P1
normal
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: Casey Yee, Assigned: steveck)

Tracking

unspecified
x86
Mac OS X

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
If a user decides to tap on the 'back' button to exit out of composing a new email we will need to prompt the user that they are about to discard the contents of the message:

"Discard email?"

[Cancel][Discard]


Tapping Cancel will return the user to the compose new email screen.

Tapping Discard will discard the new email contents and take the user back to email list view or back to the previous screen (if from activity).

Comment 1

6 years ago
Why not save the message automatically and then retrieve it based on context?
(Reporter)

Comment 2

6 years ago
Interesting idea, but i think it may be annoying in some instances where the intention is to start a new/empty email.  It may work if we had an easy way to clear fields, but we don't.

We have also discussed saving incomplete emails to a Drafts folder but it was decided given timelines and effort required to implement to go with prompt to discard.

Comment 3

6 years ago
Fair enough. Out of curiosity and since I only have the emulator to test on, is it possible, on a device, to select all the text like you would on the iOS?

Updated

6 years ago
blocking-basecamp: --- → +
Priority: -- → P1
(Assignee)

Comment 4

6 years ago
Hi Casey, I got some questions. Comment inline: 
(In reply to Casey Yee [:cyee] from comment #0)
> If a user decides to tap on the 'back' button to exit out of composing a new
> email we will need to prompt the user that they are about to discard the
> contents of the message:
> 
> "Discard email?"
> 
> [Cancel][Discard]
> 
> 
> Tapping Cancel will return the user to the compose new email screen.
                                                     ^^^^^^^^^^^^^^^^^
  Do we need to discard all the content and receivers if user choose cancel? Maybe we can just leave it unchanged? 
> 
> Tapping Discard will discard the new email contents and take the user back
> to email list view or back to the previous screen (if from activity).
Since email use window disposition for composing a new email from other activity, it is not possible to switch back to previous app. We can close the email app and back to homescreen for now.
(Assignee)

Updated

6 years ago
Assignee: nobody → schung

Comment 5

6 years ago
>   Do we need to discard all the content and receivers if user choose cancel?
> Maybe we can just leave it unchanged? 

Cancel = leaving it unchanged
Discard = deletes the compose message and returns you to the list view (inbox, etc.) or previous screen per Casey.

> > 
> > Tapping Discard will discard the new email contents and take the user back
> > to email list view or back to the previous screen (if from activity).
> Since email use window disposition for composing a new email from other
> activity, it is not possible to switch back to previous app. We can close
> the email app and back to homescreen for now.

Could we default you to the inbox if you discard?
(In reply to Chris Lee [:clee] from comment #5)
> > > Tapping Discard will discard the new email contents and take the user back
> > > to email list view or back to the previous screen (if from activity).
> > Since email use window disposition for composing a new email from other
> > activity, it is not possible to switch back to previous app. We can close
> > the email app and back to homescreen for now.
> 
> Could we default you to the inbox if you discard?

The platform is in the midst of being improved to resolve this issue, so it's a moot concern now; we can return to the originating actvity.
(Assignee)

Comment 7

6 years ago
(In reply to Andrew Sutherland (:asuth) from comment #6)
> (In reply to Chris Lee [:clee] from comment #5)
> 
> The platform is in the midst of being improved to resolve this issue, so
> it's a moot concern now; we can return to the originating actvity.

If we set the activity to disposition to window mode, it's not possible to return to originating activity.

Currently, the share activity defined in email manifest would be:

    "share": {
      "filters": {
        "type": "image/*"
       },          
      "disposition": "window",
      "returnValue": true
    }

The key to determine the mode of activity is "disposition", not activity name. That means other apps could open share activity with inline mode or window mode, and that depends on the disposition property in email manifest. Only inline mode could return to the originating actvity by calling postResult or postError(and return some data if "returnValue" is true, ).

If we really want to return, we should change our share activity to disposition: "inline" and make email runnable under inline mode. But besides that, inline mode still has some problem  now and it will cause email app crash while opening the activity. I will set activity as window mode and report this issue to system app owner.

Updated

6 years ago
Priority: P1 → --

Updated

6 years ago
Priority: -- → P1
Comment on attachment 673201 [details]
https://github.com/mozilla-b2g/gaia/pull/5899

(formalizing conditional r=asuth on the pull request from 5 days ago)
Attachment #673201 - Flags: review?(bugmail) → review+
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 10

5 years ago
Verified with Unagi, build 20121231070201
After user tapping the 'back' button to exit out of composing a new email, he/she is being prompt that they are about to discard the contents of the message: "Discard email?"
User is giving 2 options:[Cancel][Discard]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.