webapps-launch event needs to know who is the launcher.

RESOLVED WONTFIX

Status

defect
RESOLVED WONTFIX
5 years ago
2 years ago

People

(Reporter: alive, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:+)

Details

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
See Also: → 930848
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?
Flags: needinfo?(fabrice)
Flags: needinfo?(21)
(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 ?
Flags: needinfo?(21)
(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.
(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.
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)
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?
Flags: needinfo?(fabrice)
(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.
feature-b2g: --- → 2.2?
This is not committed feature for 2.2
blocking-b2g: --- → backlog
feature-b2g: 2.2? → ---
tracking-b2g: --- → +
blocking-b2g: backlog → ---
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.