Description: When a user shares media via Email App, and they close the original app (Gallery, Music, Video) they are not returned to homescreen. They are returned to homescreen if they close Browser before completing or cancelling the share. Repro Steps: 1) Updated Buri to Build ID: 20131108004004 2) Enter Gallery and select picture. 3) Choose Messages share option. 4) Long press Homescreen button and kill Gallery 5) Switch back to Email and either cancel the message or send the message to a recipient and observe. Actual: Both cases, the user stays within the message app and not returned to the homescreen. Expected: For both cases the user is returned to the homescreen when the original app has been closed by user or other event. Environmental Variables Device: Buri v1.2 COM RIL Build ID: 20131108004004 Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/a886c641a306 Gaia: 4cf40fb30c7b8380ea83ed0d4efe043b8b81737f Platform Version: 26.0 RIL Version: 01.02.00.019.102 Notes: Repro frequency: 5/5, 100%

Bug 909255 which allowed us to fix bug 802643 so that the e-mail app could return to the originating app might have something to do with this? :alive, can you comment?

I think this is my regression.

(In reply to Alive Kuo [:alive][11/4-11/8 at SFO ww.] from comment #2) > I think this is my regression. Thinking about more, I'm doubtful this is a regression. It's probably a followup bug from the work done in bug 909255. Likely isn't going to block either, as it's easy for the user to workaround this problem. I'll double check this though. QA - Can you check if this bug reproduces on a 9/5/2013 build? That will confirm if it's a regression or not.

This issue reproduces on the 9/5/2013 1.2 build using MOZ RIL. After the share event, the user remains in the Email app instead of being taken back to the Homescreen. Environmental Variables: Device: Buri v1.2 MOZ RIL BuildID: 20130905185329 Gaia: b77dc7d399c14ac2bafe5c89566b292bc6772d32 Gecko: df8f342e9a6b Version: 26.0a1

Wait.. this is not a bug. Email app is window activity which means we shouldn't treat it an inline activity window but a normal app. Why do we need to go back to homescreen?

(In reply to Jason Smith [:jsmith] from comment #3) > (In reply to Alive Kuo [:alive][11/4-11/8 at SFO ww.] from comment #2) > > I think this is my regression. > > Thinking about more, I'm doubtful this is a regression. It's probably a > followup bug from the work done in bug 909255. Likely isn't going to block > either, as it's easy for the user to workaround this problem. I'll double > check this though. > > QA - Can you check if this bug reproduces on a 9/5/2013 build? That will > confirm if it's a regression or not. Yes, you are right, this is out of scope of bug 909255. Though I did break 909255 in 911053. https://github.com/mozilla-b2g/gaia/pull/13647 would fix 909255 again. However we never talk about if the caller is closed what shall system do? 1. Relaunch caller 2. Do nothing 3. Close callee (which means go to homescreen). 4. Kill callee

Assuming this isn't covered by the spec, then this is probably a UX call and an effort should be made to update the spec. It seems like the right thing to do would be for the system app to pop up a dialog when the activity returns that says something like: "Oh no! The 'Gallery' application closed while it was in the background. Reopen it?" with OK re-opening the app and cancel dropping back to the home screen. (And this dialog would pop up over the home screen.) Haida will likely change this all a bit, so maybe the right thing to do is: - make sure the behaviour is on the TODO list to spec for haida - update whatever test case led to this bug being filed and note that the behaviour is undefined and staying in the app is fine.

IMO I don't think reopening the app is a right thing to do, because we already lost the message by postResult if the caller isn't alive when the callee do return. If we want to fix this we need some backend change I think.

needinfo-ing IxD assignee for "task manager" since it seems closest for this component to address discussion from comment 6 through comment 8. But maybe it should be :robmac instead?

As I propose in Bug# 936729, comment 24, a Share activity should be "in-line" and the user should be returned to the originating app when it's completed. If the originating app has since been killed, I agree with Alive that we shouldn't reopen the app, but instead back to the previous sheet in the stack. If there are no sheets left in the stack, then to the home screen.

Firefox OS is not being worked on