Mihail, do you feel like doing this one of these days (once the blocker has landed)?

(In reply to David Rajchenbach Teller [:Yoric] <needinfo? me> from comment #1) > Mihail, do you feel like doing this one of these days (once the blocker has > landed)? I'd love to but I do not have any estimates for when I would be able to take this bug. If this bug somehow gets its priority bumped higher, I'll get to it quicker. Anyone is welcome to take the bug. I can review patches if neeeded.

I'm working on this bug. I already have a patch here: 629607 but I want to finish the porting of Console API to worker before submit a definite implementation of this.

Actually, I confused Console.jsm with Console API. msucan do we still need this bug once bug 620935 is landed?

(In reply to Andrea Marchesini (:baku) from comment #4) > Actually, I confused Console.jsm with Console API. msucan do we still need > this bug once bug 620935 is landed? I expect we still need this bug. If I am not mistaken, this bug refers to Chrome Workers. Are Chrome Workers built on top of Web Workers? The work you are doing for bug 620935 reuses the DOM Console API implementation, which doesn't work in JSMs - there is no window object. Yoric should be able to confirm, or he can correct my understanding if I am mistaken.

Well, nothing replaces a test: can we currently use the Console API in a Chrome Worker launched without a window (i.e. from a jsm)?

This has to be tested. I'll take this bug and once Console in workers is landed, I can do this as a follow up.

About merging Console.jsm and Console.cpp I have a couple of questions. Console.jsm is not in sync with the current Console API exposed to content. It does something more and something less. I'm wondering if we care about this. Here a list: 1. ConsoleAPI is a module that can be loaded by addons and other JS code. It exposes a ConsoleAPI object, and from this object you can have a console object with some configuration: prefix, maxLogLevel, custom innerID, custom consoleID, a custom dump method. 2. it has a nice log() method that is able to dump complex object using the dump() method - by default stderr. I know that this bug is low low priority, but would be nice if we can decide how to approach it. We can maybe add some chrome-only method in the console, to set a prefix, the innerID and other stuff. Same thing can be done with the dump() method. But I don't really want to implement such complex log function. Feedbacks?

I think the solution in this case should be guided by the kinds of usage the API has in m-c and add-ons. Figuring out the first part is easy, but for the add-on case I'm not so sure. If the methods and options in question aren't widely used, let's get rid of them. Jeff might have already thought about this.

The Add-on SDK uses Console.jsm for it's own injected console object: https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/console/plain-text.js There is nothing particularly exotic about the usage, but it makes use of things like the prefix, so we'd need that in order to maintain compatibility. The use case is that an add-on author can log to the console or stdout and that the log messages are easily filtered for. If you have an ldap account you can search a private section of mxr for add-on usage - this includes any add-on hosted on AMO: https://mxr.mozilla.org/addons/search?string=resource%3A//gre/modules/devtools/Console.jsm It does not appear that there is particularly heavy usage of console.jsm in add-ons outside of the SDK.

This is not needed anymore. Console API is exposed to workers (bug 1328964). And in JSM we can use ConsoleInstance (bug 1425574).