bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

[System] Enable Go back to Activity opener from Window Disposition Activity

RESOLVED FIXED

Status

Firefox OS
Gaia::System
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: alive, Assigned: alive)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Interaction testrun 5.1 inarirun1 leorun1,inarirun2,leorun3, leorun4, retest_leorun4)

Attachments

(1 attachment)

+++ This bug was initially created as a clone of Bug #802643 +++

We want to be able to return to the calling app once the user has finished composing a message and hit send.  We can't do this super cleanly right now, here's the situation:

1) If we were an inline activity, this would work, but we can't be an inline activity without some legwork.  As discussed on https://github.com/mozilla-b2g/gaia/issues/5136, the naive approach is not viable for this; we would need to establish a postMessage bridge between the inline context and the main app context. The e-mail app is broadly architected for this, but it does assume the inline context can start up the main daemon window context (which currently also includes the UI) if it's not already up and be able to talk to it.

2) Since we are not an inline activity and not a 'pick' activity, we are unable to cause the UI to return to the previous application when we complete the activity.

3) The workaround of using window.close() which now works could be a problem without some extra hacks.  Namely, if we close ourselves, we obviously can't be sending the message while we are closed.  This requires that we have the user wait to see that the message is sent.  This may be desired for UX reasons, but it could take several seconds, and it's possible it  might fail and then the UI would need to stay up for the retries.  As a hack, we could attempt to use mozAlarms to close ourselves but then immediately re-open ourselves in the background to complete the send.

So the possible solutions are, in order of increasing level-of-effort on the behalf of the e-mail app:
A) Fix the platform so that we can return to the originating app when our activity completes.
B) Just close() ourselves once the send completes successfully.
C) close() with hack
Da) See if we can perform some kind of shell game where we create an inline activity, and when it completes, have it trigger a non-inline e-mail activity to perform the send which will immediately return, which I believe the platform does support.  This assumes various things about the platform.
Db) Do the legwork so we can just postMessage the request to ourselves from the inline activity.  This could also involve splitting ourselves into a background process and the UI process (which is what e-mail was architected to do.)
Ignore c0.

This bug is to create relationship between activity opener and window disposition activity. Currently we only "go back"(exactly it's removing the inline activities overlaid on current active app window) to app for inline activity cases.
Assignee: nobody → alive
Blocks: 802643
No longer blocks: 882421
blocking-b2g: - → ---
No longer depends on: 802643, 802108
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Summary: [email] Compose/share activities are unable to return to calling app once message is sent → [System] Enable Go back to Activity opener from Window Disposition Activity
status-b2g18-v1.0.1: affected → ---
tracking-b2g18: - → ---

Comment 2

5 years ago
Hi Alive,

Since this bug is set to block the bug 802643 in productivity team, may I know if there is any ETA to fix this one.
Flags: needinfo?(alive)
ETA is 2~3 days, however because I'm on bug 905116 which targeting the same file (window manager), I won't be able to start before 905116 is done. The ETA of 905116 is 3 more days.

I don't see any flag in bug 802643, what's the priority of it?
Flags: needinfo?(alive)
I'm on this now.
Created attachment 797794 [details]
https://github.com/mozilla-b2g/gaia/pull/11861

Patch v1: Simply remember the window disposition activity caller and display it when activity is done if there's one.

This doesn't care about
* If activity caller is dead
* If activity callee is dead
* If window->inline->window->inline....

It's difficult to trace these in this stage so I'm postponing these issues to activity window implementation.
Attachment #797794 - Flags: review?(timdream)
Tested with desktop:
1. Config an email account
2. Go go gallery, press share, choose email
3. Send the pic to alive@mozilla.com
4. The mail is sent and the gallary app is switched. YA.

Comment 7

5 years ago
Cool!
It's really nice work!
Comment on attachment 797794 [details]
https://github.com/mozilla-b2g/gaia/pull/11861

Patch v2: Add callee <-> caller reference in window position activity.
Attachment #797794 - Flags: review?(timdream)
Comment on attachment 797794 [details]
https://github.com/mozilla-b2g/gaia/pull/11861

Detected something wrong. Fixing..
Attachment #797794 - Flags: review?(timdream)
Comment on attachment 797794 [details]
https://github.com/mozilla-b2g/gaia/pull/11861

Patch v3: Set callee/caller relation and unset once each of them are killed.
Attachment #797794 - Flags: review?(timdream)
https://github.com/mozilla-b2g/gaia/commit/1398204704f78d17f5dac814e311ef13d828ac84
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Blocks: 914093
Blocks: 936734
You need to log in before you can comment on or make changes to this bug.