1123584 - Support debugging inline web activity in WebIDE

Status: RESOLVED DUPLICATE of bug 1010161

(DevTools Graveyard :: WebIDE, defect)

Description

[(inactive after 6/18) Alive Kuo [:alive]]

Current it's impossible to debug an inline activity on FirefoxOS in WebIDE
STR:
* Launch message app
* Click right-top corner to launch settings activity

The settings activity is not shown in the runtime apps list. If we click on 'Settings' it will launch the settings "app" but not jump to the settings activity.

I could help to contribute but I am still investigating how WebIDE is maintaining the runtime list.

Comment 1

[Alexandre Poirot [:ochameau]]

This report feels like a duplicate of bug 1055452.
If you open settings app before launching the activity and connect to settings BEFORE opening the activity,
the activity will appear in the iframe switching menu:
  https://developer.mozilla.org/en-US/docs/Tools/Working_with_iframes

Comment 2

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alexandre Poirot [:ochameau] from comment #1)
> This report feels like a duplicate of bug 1055452.
> If you open settings app before launching the activity and connect to
> settings BEFORE opening the activity,
> the activity will appear in the iframe switching menu:
>   https://developer.mozilla.org/en-US/docs/Tools/Working_with_iframes

Hi :ochameau! Thanks for replying. That might work,
but I wonder if we could support something like this:

=== Running Apps ===
* Homescreen app
** Wallpaper activity
* Dialer app
** Contact activity
*** Message activity

I think gaia has all the information you need here, do you think it makes sense to listen to some events from gaia system app in webide? I see an 'appOpen' event handler in appManager's base code though I don't know where does it come from.

Comment 3

[Alexandre Poirot [:ochameau]]

We are trying hard to avoid depending on gaia and, instead, rely only on platform features.
We no longer listen to any gaia event, when we did, we were used to regress as window manager was modified :/

Here is how it works now, most of the work is done on device, in the webapps actor, this is some devtools code that runs on device in order to fetch any useful information and trigger actions as you navigate in WebIDE.

For example here is where we dispatch the appOpen event from the device to firefox desktop:
http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webapps.js#1004
This code relies on Frames.jsm, a b2g specific, that could easily be moved to toolkit as it is quite generic:
  http://mxr.mozilla.org/mozilla-central/source/b2g/components/Frames.jsm
Frames relies itself on SystemAppProxy, which is more b2g-specific:
  http://mxr.mozilla.org/mozilla-central/source/b2g/components/SystemAppProxy.jsm

Having said that, the feature you describe makes sense, but as I said in bug 1055452 comment 20, it may be hard to implement it with such generic, platform only code as there isn't an API to list all frames in the child processes :'( I would prefer fixing the platform instead of relying on some gaia data/events.

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alexandre Poirot [:ochameau] from comment #3)
> We are trying hard to avoid depending on gaia and, instead, rely only on
> platform features.
> We no longer listen to any gaia event, when we did, we were used to regress
> as window manager was modified :/
> 
> Here is how it works now, most of the work is done on device, in the webapps
> actor, this is some devtools code that runs on device in order to fetch any
> useful information and trigger actions as you navigate in WebIDE.
> 
> For example here is where we dispatch the appOpen event from the device to
> firefox desktop:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/
> webapps.js#1004
> This code relies on Frames.jsm, a b2g specific, that could easily be moved
> to toolkit as it is quite generic:
>   http://mxr.mozilla.org/mozilla-central/source/b2g/components/Frames.jsm
> Frames relies itself on SystemAppProxy, which is more b2g-specific:
>  
> http://mxr.mozilla.org/mozilla-central/source/b2g/components/SystemAppProxy.
> jsm
> 
> Having said that, the feature you describe makes sense, but as I said in bug
> 1055452 comment 20, it may be hard to implement it with such generic,
> platform only code as there isn't an API to list all frames in the child
> processes :'( I would prefer fixing the platform instead of relying on some
> gaia data/events.

Agree!

But I am curious how to only rely on gecko here.
Even gecko is having the running process information, it does not know who invokes the activity right now
so it's impossible to build the connections in the list UI.

Also, it would be really hard to tell from two activities from the same app(will be in the same process).

To maintain this kind of list I somewhat think we need to actively tell gecko the relationship of iframes, and we need a new identifier other than url/manifestURL.

Comment 5

[Alexandre Poirot [:ochameau]]

We may put some metadata on the iframes, for example, today, we look for the frame whose name in "main":
  http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webapps.js#936
so that we first try to connect to the main app frame, if available. If there is no such frame we artitrary connect to the first available frame. This is the exact place that we want to tweak in order to connect to a very specific frame like activities.

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alexandre Poirot [:ochameau] from comment #5)
> We may put some metadata on the iframes, for example, today, we look for the
> frame whose name in "main":
>  
> http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/
> webapps.js#936
> so that we first try to connect to the main app frame, if available. If
> there is no such frame we artitrary connect to the first available frame.
> This is the exact place that we want to tweak in order to connect to a very
> specific frame like activities.

Actually .... the 'main' is coded in gaia :)
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/browser_frame.js#L45

And for inline activities the name should be 'inline' + id. I am not sure if this is what you want. But it's still depends on window manager though.

Comment 7

[Alexandre Poirot [:ochameau]]

Yes I know that main comes from gaia, all iframes come from gaia, but that's a very light integration with gaia codebase.
So yes, that's fine if gaia set a few attributes to help figuring out the frame hierarchy.
Ideally we would use existing attributes being already described in specs.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alexandre Poirot [:ochameau] from comment #7)
> Yes I know that main comes from gaia, all iframes come from gaia, but that's
> a very light integration with gaia codebase.
> So yes, that's fine if gaia set a few attributes to help figuring out the
> frame hierarchy.
> Ideally we would use existing attributes being already described in specs.

I'd like to help if you think it's fine to have some attributes like
<iframe data-id="abc" src="...."></iframe>
<iframe data-id="def" data-parent-id="ghi" src="...."></iframe>

Comment 9

[Alexandre Poirot [:ochameau]]

Let's continue the discussion in the historical bug...