(inactive after 6/18) Alive Kuo [:alive] Reporter
	Description • 10 years ago

Use case:
Settings app -> keyboard app(s) -> back to settings app.
Now this is done by new MozActivity with 'config',
but Settings app is going to support disposition: inline in v2.0

We cannot have (3rd-party) keyboard app(s) to call inline activity for 'back to the settings' because this doesn't make sense.

See https://bugzilla.mozilla.org/show_bug.cgi?id=930848#c0 as well

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 1 • 10 years ago

Fabrice, what if we make this happen with adding a property in event.detail.extra just like system message does?
Vivien, what do you think?

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
	Comment 2 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #1)
> Fabrice, what if we make this happen with adding a property in
> event.detail.extra just like system message does?
> Vivien, what do you think?

Just curious how would you differentiate between the keyboard use case and https://bugzilla.mozilla.org/show_bug.cgi?id=930848#c4 ?

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 3 • 10 years ago

(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #2)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #1)
> > Fabrice, what if we make this happen with adding a property in
> > event.detail.extra just like system message does?
> > Vivien, what do you think?
> 
> Just curious how would you differentiate between the keyboard use case and
> https://bugzilla.mozilla.org/show_bug.cgi?id=930848#c4 ?

Ya that is my pain...but what if we don't care? I mean if any window.close leads to the app launches it seems not too strange to me. For crash(mozbrowsererror) we won't launch the caller.

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 4 • 10 years ago

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #3)
> (In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails,
> needinfo? please) from comment #2)
> > (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #1)
> > > Fabrice, what if we make this happen with adding a property in
> > > event.detail.extra just like system message does?
> > > Vivien, what do you think?
> > 
> > Just curious how would you differentiate between the keyboard use case and
> > https://bugzilla.mozilla.org/show_bug.cgi?id=930848#c4 ?
> 
> Ya that is my pain...but what if we don't care? I mean if any window.close
> leads to the app launches it seems not too strange to me. For
> crash(mozbrowsererror) we won't launch the caller.

Another proposal:
If the previous app is the app caller when the app closes itself, back to it.
If the user returns to homescreen or switch to other app, forget the link.

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
	Comment 5 • 10 years ago

So I think what you can do in order to know the exact iframe that has asked to launch the app is:

 - Modify the code at http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1083 so it returns you the iframe element that has send the message trought IPC
 - Forward a reference to this element in the observer at http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1252 instead of null for the subject.
 - Use this reference in shell.js to dispatch the webapps-launch event on the relevant iframe (look at http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/devtools.js?force=1#275 where you can specify a target to dispatch the event too)

	[:fabrice] Fabrice Desré
	Comment 6 • 10 years ago

Yep, that can work. We are refactoring the Webapps.jsm -> (everyone else) glue to not use observers but I'll add the launcherFrame to the relevant interfaces.

One question though, when the launch() call comes from an iframe in a page, do you want this iframe or the top level one?

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 7 • 10 years ago

(In reply to Fabrice Desré [:fabrice] from comment #6)
> Yep, that can work. We are refactoring the Webapps.jsm -> (everyone else)
> glue to not use observers but I'll add the launcherFrame to the relevant
> interfaces.
> 
> One question though, when the launch() call comes from an iframe in a page,
> do you want this iframe or the top level one?

I think I cannot locate the inner iframe without API support.
So my answer is top level.

	howie [:howie]
	Comment 8 • 10 years ago

This is not committed feature for 2.2

	BMO Automation
	Comment 9 • 6 years ago

Firefox OS is not being worked on