1249709 - Expose console through worker loader

Status: RESOLVED WONTFIX

(DevTools :: Console, defect, P2)

Description

[Brian Grinstead [:bgrins]]

As of Bug 1246784, the Console object should be exposed to the worker debugger global scope.  I believe we still need to do a bit of extra work to expose it through the loader, since it's still throwing when trying to console.log() if isWorker is true.

I believe this is also needed for Bug 1246091

Comment 1

[Brian Grinstead [:bgrins]]

Attachment: console-worker-loader.patch

Here's a patch that exposes console to the global in JS through the loader.  Calling console.log() works now in the sense that it doesn't throw, but it's output isn't show up in stdout or the browser console when it's running the worker scope.

STR for log not showing up in stdout:
 1) Set devtools.debugger.workers = true
 2) Load https://bgrins.github.io/devtools-demos/worker/webworker.html
 3) Open debugger and click on hello-worker.js?0
 4) Switch to console panel in new window that's popped up

Should see a log like: "Creating webconsole actor true" but nothing shows up.  Of course it does work when the ConsoleActor is loaded in the main thread.

Andrea, do you know why these console messages might be disappearing, and if there's a way to make them show up?  I'm not actually sure how normal messages end up showing up in stdout.

Comment 2

[Eddy Bruel [:ejpbruel]]

This bug belongs to the console component.

Comment 3

[Andrea Marchesini [:baku]]

> Andrea, do you know why these console messages might be disappearing, and if
> there's a way to make them show up?  I'm not actually sure how normal
> messages end up showing up in stdout.

I think that what you see is not the Console API we changed, but it's the console API written by/for the devtools in jsm: toolkit/modules/Console.jsm

If you do dump("Console object: " + console.toSource() + " console.log: " + console.log + "\n");
you will see that the console object is:

Console object: ({dump:(function bound dump() {
    [native code]
}, prefix:"", _maxExplicitLogLevel:(void 0), _maxLogLevel:(void 0), innerID:null, consoleID:"", debug:(function bound () {
    [native code]
}, log:(function bound () {
    [native code]
}, info:(function bound () {
    [native code]
}, warn:(function bound () {
    [native code]
}, error:(function bound () {
    [native code]
}, exception:(function bound () {
    [native code]
}, trace:(function bound Console_trace() {
    [native code]
}, clear:(function bound Console_clear() {
    [native code]
}, dir:(function bound () {
    [native code]
}, dirxml:(function bound () {
    [native code]
}, group:(function bound () {
    [native code]
}, groupEnd:(function bound () {
    [native code]
}, time:(function bound Console_time() {
    [native code]
...

Comment 4

[Brian Grinstead [:bgrins]]

Attachment: console-worker-loader.patch

OK, progress.  I've gotten further along now and am confirming that the 'console' in the WebConsoleActor for the worker debugger is not console.jsm and in fact native code.  So that's great and hopefully will let us use functionality from Bug 1246091.

One thing that's still not working: console.log statements aren't showing up in stdout but they DO show up in the Browser Console.  Here are full STR:

1) Set browser.dom.window.dump.enabled to see any dump() output when opening the worker toolbox
2) Set devtools.debugger.workers = true
3) Load https://bgrins.github.io/devtools-demos/worker/webworker.html
4) Open debugger and click on hello-worker.js?0
5) Switch to console panel in new window that's popped up

I do see this as expected:

  WebConsoleActor created true
  Console object: ({}) console.log: function log() {
      [native code]
  }

But I'm not seeing the "This should show up in stdout but it doesn't seem to" message in stdout.  I guess it's not a huge deal since it shows up in the Browser Console but it could be one of those weird things that bites someone in the future when they are looking at logs in the program output.  So if there's an easy fix for this now we should include it.  Any ideas?

Comment 5

[Andrea Marchesini [:baku]]

> One thing that's still not working: console.log statements aren't showing up
> in stdout but they DO show up in the Browser Console.  Here are full STR:

Console API doesn't write anything to stderr/stdout.
Only Console.jsm does it but I don't think it's a useful feature for Console API.
This API is exactly the same that we expose to content.

If you really need this, file a separate bug for it. Thanks!

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to Andrea Marchesini (:baku) from comment #5)
> > One thing that's still not working: console.log statements aren't showing up
> > in stdout but they DO show up in the Browser Console.  Here are full STR:
> 
> Console API doesn't write anything to stderr/stdout.
> Only Console.jsm does it but I don't think it's a useful feature for Console
> API.
> This API is exactly the same that we expose to content.
> 
> If you really need this, file a separate bug for it. Thanks!

OK, I guess I'm just used to seeing the output from Console.jsm.  Having it show up in Browser Console is good enough and will make logging in the worker debugger a lot easier.

Comment 7

[Brian Grinstead [:bgrins]]

Attachment: MozReview Request: Bug 1249709 - Expose console through worker loader;r=ejpbruel

Review commit: https://reviewboard.mozilla.org/r/42343/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/42343/

Comment 8

[Brian Grinstead [:bgrins]]

Comment on attachment 8734534 [details]
MozReview Request: Bug 1249709 - Expose console through worker loader;r=ejpbruel

Actually, maybe we don't need this after all.  It looks like retrieveConsoleEvents and setConsoleEventHandler are attached directly to the worker debugger global scope so don't need to reach it through the console.

Plus this has the unfortunate side effect of logs from worker debugger showing up in the page's console, so we could accidentally spam someones console if a call to console.error or console.log was left in actor.

Comment 9

[Brian Grinstead [:bgrins]]

See comment 8