Closed
Bug 909255
Opened 11 years ago
Closed 11 years ago
[System] Enable Go back to Activity opener from Window Disposition Activity
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: alive, Assigned: alive)
References
Details
(Whiteboard: Interaction testrun 5.1 inarirun1 leorun1,inarirun2,leorun3, leorun4, retest_leorun4)
Attachments
(1 file)
+++ 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.)
Assignee | ||
Comment 1•11 years ago
|
||
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
blocking-b2g: - → ---
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
Assignee | ||
Updated•11 years ago
|
status-b2g18-v1.0.1:
affected → ---
tracking-b2g18:
- → ---
Comment 2•11 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)
Assignee | ||
Comment 3•11 years ago
|
||
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)
Assignee | ||
Comment 4•11 years ago
|
||
I'm on this now.
Assignee | ||
Comment 5•11 years ago
|
||
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)
Assignee | ||
Comment 6•11 years ago
|
||
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•11 years ago
|
||
Cool!
It's really nice work!
Comment 8•11 years ago
|
||
Comment on attachment 797794 [details]
https://github.com/mozilla-b2g/gaia/pull/11861
Discussed offline.
Attachment #797794 -
Flags: review?(timdream)
Assignee | ||
Comment 9•11 years ago
|
||
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)
Assignee | ||
Comment 10•11 years ago
|
||
Comment on attachment 797794 [details]
https://github.com/mozilla-b2g/gaia/pull/11861
Detected something wrong. Fixing..
Attachment #797794 -
Flags: review?(timdream)
Assignee | ||
Comment 11•11 years ago
|
||
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)
Comment 12•11 years ago
|
||
Comment on attachment 797794 [details]
https://github.com/mozilla-b2g/gaia/pull/11861
Looks good.
Attachment #797794 -
Flags: review?(timdream) → review+
Assignee | ||
Comment 13•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•