Description: All sharing option such as "Email" "Set Ringtone" Bluetooth Transfer" have a cancel button and a user can return to the music file if he changed his mind to share it But when the user is canceling sharing via SMS the user is returned to the SMS group thread Repro Steps: 1) Updated Buri to BuildID: 20140109004002 2) Open the "Music" app 3) Choose any music file 4) Tap the "share" icon 5) Choose "Message" 6) Tap the "<" "back" icon 7) Tap the "OK" button on the "discard" this message Actual: The user is returned to the message thread Expected: The user is returned to the audio file that he tried to send before Environmental Variables: Device: Buri 1.3 MOZ BuildID: 20140109004002 Gaia: 22bc6be5b76cdc6d4e9667ff070979041a20ce2f Gecko: 2c8f8683bd0d Version: 28.0a2 Firmware Version:v1.2_2013115 Notes: Repro frequency: 100% See attached: screenshot

The bug reproduce on 1.2 All sharing options except "Messages" having a choice return to the audio file without opening the music app again 1.2 Environmental Variables: Device: Buri 1.2 MOZ BuildID: 20140108004002 Gaia: 539a25e1887b902b8b25038c547048e691bd97f6 Gecko: 0d8b879ffd70 Version: 26.0 Firmware Version: 20131115

Since the "discard" option menu only exists in master(message draft feature), we might need a different patch for v1.3 and earlier branch if we want to fix for v1.3.

Hey Steve, we have another bug to move the "share" activity to "inline" instead of "window", I think it would fix this bug too and that this bug is a dupe. See bug 936729 (assigned to alive but I think it's wrong).

(In reply to Julien Wajsberg [:julienw] from comment #3) > Hey Steve, > > we have another bug to move the "share" activity to "inline" instead of > "window", I think it would fix this bug too and that this bug is a dupe. > > See bug 936729 (assigned to alive but I think it's wrong). If we move the "share" activity to "inline", what if we use another inline activity to pick the the contact? I think both inline/window could solve this case, just need to make sure we handle activity postResul/postError properly.

To me: * "inline" means that at the end of the activity's job, we need to go back at the calling app * "window" means that we change the context (eg: we want to see an URL in the browser), and when the activity has done its job, we should not move back to the calling application (we don't want to go back to SMS once the URL is displayed in the browser). That's why I think we need to move to "inline" here. But maybe we do have another issue when discarding the content.