Closed Bug 802733 Opened 12 years ago Closed 12 years ago

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

Categories

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P1)

x86
macOS
defect

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: caseyyee.ca, Assigned: steveck)

Details

Attachments

(1 file)

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).
Why not save the message automatically and then retrieve it based on context?
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.
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?
blocking-basecamp: --- → +
Priority: -- → P1
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: nobody → schung
>   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.
(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.
Attachment #673201 - Flags: review?(bugmail)
Priority: P1 → --
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+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: