863818 - console.log messages don't appear in the Web Console when connecting to "shell.xul" via Simulator

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[Will Bamberg [:wbamberg]]

Using the Firefox OS Simulator (3.0pre6), if I select "Connect..." to connect the developer tools, I get a choice:

  Available remote tabs:
      chrome://prosthesis/content/shell.xul
  Available remote processes:
      Main Process

If I choose "chrome://prosthesis/content/shell.xul", then console.log() messages don't appear in the Web Console. I do see them in the Error Console, and if I choose "Main Process" in the "Connect" tab, then I also see them.

I've tried this with the current Aurora and Nightly.

Comment 1

[Mihai Sucan [:msucan]]

From which window do you call window.console APIs? It will only work for the shell.xul window object itself and iframe children that still have their window.top pointing to the shell.xul window object.

Comment 2

[Will Bamberg [:wbamberg]]

(In reply to Mihai Sucan [:msucan] from comment #1)
> From which window do you call window.console APIs?

I'm calling it from within a web app running in the Simulator.

> It will only work for the
> shell.xul window object itself and iframe children that still have their
> window.top pointing to the shell.xul window object.

So is this not expected to work? If it isn't, that's fine: I just need to know what I should recommend that people do here.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

(In reply to Will Bamberg [:wbamberg] from comment #2)
> (In reply to Mihai Sucan [:msucan] from comment #1)
> > It will only work for the
> > shell.xul window object itself and iframe children that still have their
> > window.top pointing to the shell.xul window object.
> 
> So is this not expected to work? If it isn't, that's fine: I just need to
> know what I should recommend that people do here.

Mihai should confirm, but I think that's correct. :-/

shell.xul loads the homescreen app in a mozbrowser iframe <https://github.com/mozilla/mozilla-central/blob/9a87ff0bedbdae5c9381e5d34f6663b8438046e3/b2g/chrome/content/shell.js#L256-L263>, which means the homescreen app's window.top will point to itself, per the browser API <https://developer.mozilla.org/en-US/docs/WebAPI/Browser>.

And Gaia's system app loads other apps in their own mozbrowser iframes <https://github.com/mozilla-b2g/gaia/blob/8c8d831f6e3371e526e91c443688ff600dc82dfe/apps/system/js/window_manager.js#L1208-L1211>, so the situation is the same for them.

Ideally, we'd be able to connect users directly to the iframe for a given app, so the debugger would show only the scripts for that app, and the console would show only the messages for that app.

Mihai: is there an API that the Simulator could use to add app iframes to the list of "available remote tabs"?  Or some other means of achieving that goal?

Comment 4

[Mihai Sucan [:msucan]]

(In reply to Will Bamberg [:wbamberg] from comment #2)
> (In reply to Mihai Sucan [:msucan] from comment #1)
> > From which window do you call window.console APIs?
> 
> I'm calling it from within a web app running in the Simulator.
> 
> > It will only work for the
> > shell.xul window object itself and iframe children that still have their
> > window.top pointing to the shell.xul window object.
> 
> So is this not expected to work? If it isn't, that's fine: I just need to
> know what I should recommend that people do here.

This is not expected to work. I suggest you always attach to the main process when you plan to use the web console. This is until we have a better way to attach to a specific app.


(In reply to Myk Melez [:myk] [@mykmelez] from comment #3)
> (In reply to Will Bamberg [:wbamberg] from comment #2)
> > (In reply to Mihai Sucan [:msucan] from comment #1)
> > > It will only work for the
> > > shell.xul window object itself and iframe children that still have their
> > > window.top pointing to the shell.xul window object.
> > 
> > So is this not expected to work? If it isn't, that's fine: I just need to
> > know what I should recommend that people do here.
> 
> Mihai should confirm, but I think that's correct. :-/
> 
> shell.xul loads the homescreen app in a mozbrowser iframe
> <https://github.com/mozilla/mozilla-central/blob/
> 9a87ff0bedbdae5c9381e5d34f6663b8438046e3/b2g/chrome/content/shell.js#L256-
> L263>, which means the homescreen app's window.top will point to itself, per
> the browser API <https://developer.mozilla.org/en-US/docs/WebAPI/Browser>.
> 
> And Gaia's system app loads other apps in their own mozbrowser iframes
> <https://github.com/mozilla-b2g/gaia/blob/
> 8c8d831f6e3371e526e91c443688ff600dc82dfe/apps/system/js/window_manager.
> js#L1208-L1211>, so the situation is the same for them.
> 
> Ideally, we'd be able to connect users directly to the iframe for a given
> app, so the debugger would show only the scripts for that app, and the
> console would show only the messages for that app.

Yes.

> Mihai: is there an API that the Simulator could use to add app iframes to
> the list of "available remote tabs"?  Or some other means of achieving that
> goal?

Afaik there's no such API. You would need to change dbg-browser-actors.js in b2g/ to present those iframes. For the purposes of the console actors it could be easier to have actors per iframe. I think it's more complex with the js debugger. I see there's a new dbg-webapps-actors.js - isn't that something you need? I haven't followed this parts of the code too closely.

Panos: I'm sure you can explain things better than myself.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

(In reply to Mihai Sucan [:msucan] from comment #4)
> Afaik there's no such API. You would need to change dbg-browser-actors.js in
> b2g/ to present those iframes.

We should be able to do that.


> For the purposes of the console actors it
> could be easier to have actors per iframe. I think it's more complex with
> the js debugger.

I'm game for doing it however y'all think is best.


> I see there's a new dbg-webapps-actors.js - isn't that
> something you need? I haven't followed this parts of the code too closely.

Yes, we already bundle that with the Simulator, which is how the Simulator addon installs apps into the Simulator application.

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

I didn't know that console.log didn't work in the shell.xul case, that's a bummer. So we still don't have at least one debugging target for b2g that results in all of our tools working. I've noticed that the network inspector has the same issues as the console with the shell.xul target. Maybe we should give another shot at porting the chrome debugging patches to mozilla-b2g18 and using them in the simulator? That way we could automatically select the Main Process target, until subprocess support lands.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #3)
> Mihai: is there an API that the Simulator could use to add app iframes to
> the list of "available remote tabs"?  Or some other means of achieving that
> goal?

We had a patch in bug 817580 to do just that, but it was deemed inappropriate for inclusion into b2g, due to the synchronous nature of the calls to enumerate running apps. I tried to make it async, but the API I used is a dead end until bug 797627 arrives. If you want to use it in the simulator, you will need the previous version (#2) of the patch.

Comment 7

[Mihai Sucan [:msucan]]

Panos: I talked to Rob about one older idea I had for the shell.xul console actor: we can add a simple workaround to the tab-specific console actor, to make it behave like the global console actor. This would allow all messages to show even if users pick shell.xul, and they would also be able to use the debugger while using the console (with b2g18). I remember that back when I made the workaround proposal (around the time when we added support for the remotable web console), we agreed that it is preferable to a have a real fix for the issue. However, given the time constrains we have, and that we do not yet have a correct solution, I believe the workaround is simple enough and useful for b2g users. We are currently waiting for multiple subprocesses support in the debugger - which will hopefully allow us to better identify which messages belong to which app.

I will submit a patch for the mozilla-b2g18 repo and I would like to do this for mozilla-central as well (given many use the latest code). In m-c (and even in b2g18) we can remove the workaround when we will have a better fix.

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

If the implementation is not too hacky, I'm fine with the idea.

Comment 9

[Mihai Sucan [:msucan]]

Attachment: proposed workaround (for fx-team repo)

This patch overrides the case when the b2g tab actor is picked - it always behaves as the global console actor.

I have two concerns here:

1. I am not sure if the check is good enough. Should we use an ifdef MOZ_WIDGET_GONK?

2. I only tested with b2g-desktop builds and the patch works. We should have tests so we can push to the try server to check if we break android/b2g support.

Please let me know if you want any changes. I'd like to keep the workaround isolated to the dbg-webconsole-actors file -- not inside the dbg-browser-actors. Since this is a console thing I believe it makes sense to not involve other code.

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

Comment on attachment 750633 [details] [diff] [review]
proposed workaround (for fx-team repo)

Review of attachment 750633 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Mihai Sucan [:msucan] from comment #9)
> This patch overrides the case when the b2g tab actor is picked - it always
> behaves as the global console actor.

I like it!

> I have two concerns here:
> 
> 1. I am not sure if the check is good enough. Should we use an ifdef
> MOZ_WIDGET_GONK?

We're trying to remove preprocessing since it doesn't play well with the loader work. A dynamic check like this should suffice.

> 2. I only tested with b2g-desktop builds and the patch works. We should have
> tests so we can push to the try server to check if we break android/b2g
> support.

We need more xpcshell test coverage for the console, since currently that's our best bet for b2g & fennec, but this won't help testing this particular change. We need Marionette tests for b2g and maybe Robocop tests for Fennec.

I'll do a manual test for both devices and report back.

Comment 11

[Mihai Sucan [:msucan]]

(In reply to Panos Astithas [:past] from comment #10)
> > I have two concerns here:
> > 
> > 1. I am not sure if the check is good enough. Should we use an ifdef
> > MOZ_WIDGET_GONK?
> 
> We're trying to remove preprocessing since it doesn't play well with the
> loader work. A dynamic check like this should suffice.

Good point. I asked because I see an ifdef for chrome debugging in the b2g browser actors script.

> > 2. I only tested with b2g-desktop builds and the patch works. We should have
> > tests so we can push to the try server to check if we break android/b2g
> > support.
> 
> We need more xpcshell test coverage for the console, since currently that's
> our best bet for b2g & fennec, but this won't help testing this particular
> change. We need Marionette tests for b2g and maybe Robocop tests for Fennec.
> 
> I'll do a manual test for both devices and report back.

Thank you! Once you have results back I will also submit a patch for mozilla-b2g18.

Comment 12

[Panos Astithas (he/him) [:past] (please ni?)]

Fennec works fine. I didn't test a b2g device because the web console is disabled on build time, so I think we're good to go.

Comment 13

[Mihai Sucan [:msucan]]

(In reply to Panos Astithas [:past] from comment #12)
> Fennec works fine. I didn't test a b2g device because the web console is
> disabled on build time, so I think we're good to go.

Thanks for testing. Landed in fx-team:
https://hg.mozilla.org/integration/fx-team/rev/bbc2b4a57455

Will submit a patch for mozilla-b2g.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/bbc2b4a57455

Comment 15

[Mihai Sucan [:msucan]]

Attachment: patch for b2g18

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): new feature - remote web console, bug 768096.
User impact if declined: users who select the shell.xul tab in the devtools connection window will see that the remote web console shows very few messages.
Testing completed: landed in mozilla-central and manual testing.
Risk to taking this patch (and alternatives if risky): minimal.
String or UUID changes made by this patch: none.

Thank you!

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/674d2e320794

Comment 17

[Mihai Sucan [:msucan]]

Thank you!