Intent to Deprecate: Console.jsm as a generic console in favor of the WebIDL console

[Nick Fitzgerald]

https://bugzilla.mozilla.org/show_bug.cgi?id=1191571

Console.jsm is a huge step backwards compared to the builtin WebIDL console
that is exposed to the web[0]:

* Console.jsm doesn't support rendering time/timeEnd in the profiler
waterfall
* Console.jsm doesn't support profile/profileEnd
* Etc... See more in https://bugzilla.mozilla.org/show_bug.cgi?id=1191571#c8

Additionally, it is wasted, duplicate effort, and the console that is
exposed to the web will always be the Real Console by default.

Because of that, I'm exposing the WebIDL console to system globals and
removing Console.jsm from the globals created by the loader. Because the
WebIDL console will be exposed to all system globals, we won't need any
explicit loader integration anymore. I'm also removing most imports of
Console.jsm.

IF YOU JUST WANT TO CONSOLE.LOG SOMETHING WHILE DEBUGGING, NOTHING IS
CHANGING FOR YOU.

Additionally, note that I am not fully removing Console.jsm, as the
addon-sdk seems to depend on its funkiness and there was talk about adding
devtools-specific logging and high level tracing that leverages its prefix
support. This won't make that possibility go away. However, neither of
those things warrants us being stuck with an inferior console that lacks
the support of the WebIDL console.

[Brian Grinstead]

Does the WebIDL console log to stdout? (I can’t check because with the current patch queue applied on 1191571 I get 'console is not defined’ errors when opening the toolbox).

We had to add reference to Console.jsm from mochitests so that we didn’t have missing log statements in the test output (bug 1175318). It’s also expected that you'll see console statements show up in stdout when running the process locally.

Brian

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools

[Nick Fitzgerald]

The patches are still a bit of a WIP, but I've attached some new versions
that should function correctly.

The WebIDL console does not log to stdout. We could make a console observer
that dumps to stdout pretty easily though.

On Wed, Aug 5, 2015 at 6:03 PM, Brian Grinstead <bgrin...@mozilla.com>
wrote:

[J. Ryan Stinnett]

On Wed, Aug 5, 2015 at 7:04 PM, Nick Fitzgerald <nfitz...@mozilla.com> wrote:
> Additionally, note that I am not fully removing Console.jsm, as the
> addon-sdk seems to depend on its funkiness and there was talk about adding
> devtools-specific logging and high level tracing that leverages its prefix
> support. This won't make that possibility go away. However, neither of
> those things warrants us being stuck with an inferior console that lacks
> the support of the WebIDL console.

I don't really follow this part. If we decide to use Console.jsm as
our logger with more log levels, prefixes, etc. won't we need to
essentially revert everything you are doing here, so that console
calls flow through it again?

- Ryan

[Brian Grinstead]

Here are the main features I can think of that Console.jsm has that the WebIDL console doesn't:

1) Logging to stdout. This seems like a blocker to making any change. You mention we could handle this with a console observer, where / how could that be implemented?
2) Conditional log levels based on a pref. This allows you to have log statements in your code that only show up if a certain pref is set. Here's an example of that in the Download UI: https://dxr.mozilla.org/mozilla-central/source/browser/components/downloads/DownloadsCommon.jsm#69.
3) Prefixed logging. This allows you to scan and filter results in the Browser Console that came from your logger: https://dxr.mozilla.org/mozilla-central/source/browser/components/downloads/DownloadsCommon.jsm#70

With regard to points 2 and 3, people could still construct their own ConsoleAPIs regardless of your proposal so it isn’t strictly breaking that workflow.

But, if we are going to say that Console.jsm's logging isn't good enough for us, I think we should make an effort to bring along the teams that we support as well. Is there a potential path where we could make Console.jsm (or a similar module) use the WebIDL console for it's logging implementation? Seems we could do that with 2, but I'm not sure about 3. Is there a way to get the WebIDL console to send a prefix to recordEvent?

Brian

> On Aug 5, 2015, at 7:17 PM, Nick Fitzgerald <nfitz...@mozilla.com> wrote:
>
> The patches are still a bit of a WIP, but I've attached some new versions that should function correctly.
>
> The WebIDL console does not log to stdout. We could make a console observer that dumps to stdout pretty easily though.
>
> On Wed, Aug 5, 2015 at 6:03 PM, Brian Grinstead <bgrin...@mozilla.com> wrote:
> Does the WebIDL console log to stdout? (I can’t check because with the current patch queue applied on 1191571 I get 'console is not defined’ errors when opening the toolbox).
>
> We had to add reference to Console.jsm from mochitests so that we didn’t have missing log statements in the test output (bug 1175318). It’s also expected that you'll see console statements show up in stdout when running the process locally.
>
> Brian
>
> > On Aug 5, 2015, at 5:04 PM, Nick Fitzgerald <nfitz...@mozilla.com> wrote:
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1191571
> >
> > Console.jsm is a huge step backwards compared to the builtin WebIDL console
> > that is exposed to the web[0]:
> >
> > * Console.jsm doesn't support rendering time/timeEnd in the profiler
> > waterfall
> > * Console.jsm doesn't support profile/profileEnd
> > * Etc... See more in https://bugzilla.mozilla.org/show_bug.cgi?id=1191571#c8
> >
> > Additionally, it is wasted, duplicate effort, and the console that is
> > exposed to the web will always be the Real Console by default.
> >
> > Because of that, I'm exposing the WebIDL console to system globals and
> > removing Console.jsm from the globals created by the loader. Because the
> > WebIDL console will be exposed to all system globals, we won't need any
> > explicit loader integration anymore. I'm also removing most imports of
> > Console.jsm.
> >
> > IF YOU JUST WANT TO CONSOLE.LOG SOMETHING WHILE DEBUGGING, NOTHING IS
> > CHANGING FOR YOU.
> >

> > Additionally, note that I am not fully removing Console.jsm, as the
> > addon-sdk seems to depend on its funkiness and there was talk about adding
> > devtools-specific logging and high level tracing that leverages its prefix
> > support. This won't make that possibility go away. However, neither of
> > those things warrants us being stuck with an inferior console that lacks
> > the support of the WebIDL console.