Closed Bug 731074 Opened 12 years ago Closed 11 years ago

console.log not working from a panel's script

Categories

(Add-on SDK Graveyard :: General, defect, P1)

x86_64
Windows 7
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: KWierso, Assigned: zer0)

References

()

Details

Attachments

(2 files)

In the addon linked from this bug's URL, if you click the widget that the addon adds to the addon bar, a panel pops up. If you click the panel's "Log" button, the panel script should log a message to the console, then emit an event back to the main addon script, which logs it again.

As far as I can tell, only the message emitted back to the main addon script is getting logged.

In that panel's script, there's an alert(console.log), which tells me that the console object is defined, and that console.log is a function. It just doesn't seem to be getting logged to where it needs to.

Is the panel implementation eating the logged messages and not passing them on to the various consoles (web/error/terminal)?
(In reply to Wes Kocher (:KWierso) (Jetpack Bugmaster) from comment #0)
> Is the panel implementation eating the logged messages and not passing them
> on to the various consoles (web/error/terminal)?

In this version ( https://builder.addons.mozilla.org/addon/1042249/latest/ ), the addon opens the page in a new tab. If you install the addon and have the addon open the new tab, then open the web console (Ctrl-Shift-K for me here on Windows, not sure about other platforms), then click the tab's "Log" button, I see the message being logged to the web console, but not any of the other consoles.
We aren't overloading `console` object in UI documents. So that it is not "our" console API but the platform one. Unfortunatly, for all APIs but Tab/PageMod, so Panel, Page-Worker, we can't see these log message anywhere. 
The platform "console" object only works for documents in tabs where they can appear in the web console.

We may have to modify devtools code in order to properly fix this.
We should be able to trap these messages if we decide to implement a custom "Jetpack console".

I already played with WebConsole code in order to build a jetpack console. This work is now broken due to the new loader that evaluate modules in a frameManager (using <browser>).
A contributor is working on an important patch in bug 673148, that will allow to make it work again.
Alex, do you want to reach out to the devtools guys if we need any help here?
Priority: -- → P2
Should this be a P1? It's a pretty surprising result, and makes debugging panel code really hard.
Seems a little surprising to me too, let's talk about it in next triage.
Priority: P2 → --
Assignee: nobody → zer0
(Matteo pinged me on IRC about this bug, replying here)

The platform implementation of the window.console API stores messages for every window object. See ConsoleAPI.js and ConsoleAPIStorage.jsm. (hg locate)

In the Web Console we filter out all of the console API messages that do not belong to the current tab - that would mean too much information (extensions/addons, other tabs, etc).

Our current plan is to add a Global Console which will show all errors and all console API calls, including those coming from extensions. See bug 587757.

We recognize the need to allow extensions and any other browser component to output messages specific to a tab, inside the Web Console output. For that, we do not yet have a clean API. In Bug 778766 we plan to fix this.

In the meantime, you can work around the above problem by temporarily overwriting the panel's window.console object with code that calls the tab's window.console methods. Do note we have filter options to disable page's console messages, which will confuse users when they see messages from extensions.

Another approach would be to get the Web Console instance for the current tab and output a message directly. As mentioned, there's no clean API, but you can hack something - see WCF_logWarningAboutReplacedAPI() in webconsole.js for a simple/minimal way to add a message.

I suggest that the second approach is picked - it's less hacky/confusing, and we can update it to use the new web console output API, once it's ready.

In general I would suggest we keep the number of things that can end up in the web console output under control. Web pages already generate a lot of output. For extensions we should favor the Global Console.

Thoughts:

- if we allow console messages from jetpack panels to show in the web console for the current tab, should we also show script errors from those panels?

- could jetpack provide a separate API to output messages into any web console the dev chooses? This could be interesting: developers would be given the choice to output to a generic global console, or to output a message for a specific tab.


Please let me know if you have any questions.
(In reply to Mihai Sucan [:msucan] from comment #6)
...
> - if we allow console messages from jetpack panels to show in the web
> console for the current tab, should we also show script errors from those
> panels?

Yes.

> - could jetpack provide a separate API to output messages into any web
> console the dev chooses? This could be interesting: developers would be
> given the choice to output to a generic global console, or to output a
> message for a specific tab.

It's part of my evil plan that the SDK should allow any add-on to pipe info to the web console - a la FirePHP.
(In reply to Jeff Griffiths (:canuckistani) from comment #7)
> (In reply to Mihai Sucan [:msucan] from comment #6)
> ...
> > - if we allow console messages from jetpack panels to show in the web
> > console for the current tab, should we also show script errors from those
> > panels?
> 
> Yes.

Would the Global Console be sufficient for this purpose? Or jetpack addon panels are tab-bound somehow?

> > - could jetpack provide a separate API to output messages into any web
> > console the dev chooses? This could be interesting: developers would be
> > given the choice to output to a generic global console, or to output a
> > message for a specific tab.
> 
> It's part of my evil plan that the SDK should allow any add-on to pipe info
> to the web console - a la FirePHP.

Nice evil plan. :) This sounds cool and this is what we want to support.
(In reply to Mihai Sucan [:msucan] from comment #8)
...
> Would the Global Console be sufficient for this purpose? Or jetpack addon
> panels are tab-bound somehow?

The Global console makes the most sense to me. Conceptually, 'tab-bound' add-ons sounds pretty strange. In terms of UX, do you think this 'add-on/<add-on-name>' console channel could be made sticky / visible in all tabs? Is that how the global console will work?

> > > - could jetpack provide a separate API to output messages into any web
> > > console the dev chooses? This could be interesting: developers would be
> > > given the choice to output to a generic global console, or to output a
> > > message for a specific tab.
> > 
> > It's part of my evil plan that the SDK should allow any add-on to pipe info
> > to the web console - a la FirePHP.
> 
> Nice evil plan. :) This sounds cool and this is what we want to support.

Yeah, I see the console module as something that just receives messages of some sort and, if the user has chosen this, displays them. To implement FirePHP support all the add-onb developer would need to do is write / steal the FirePHP data parser and duck-tape the whole thing together. This reminds me, I need to write out my ideas more concretely and socialize them.
(In reply to Jeff Griffiths (:canuckistani) from comment #9)
> (In reply to Mihai Sucan [:msucan] from comment #8)
> ...
> > Would the Global Console be sufficient for this purpose? Or jetpack addon
> > panels are tab-bound somehow?
> 
> The Global console makes the most sense to me. Conceptually, 'tab-bound'
> add-ons sounds pretty strange. In terms of UX, do you think this
> 'add-on/<add-on-name>' console channel could be made sticky / visible in all
> tabs? Is that how the global console will work?

Yes, the plan is to open a separate window, like the Error Console, but this would be the Global Console which will have almost the same UI/UX as the Web Console. It will not be tab-bound, and you'll be able to keep it always visible.
Just want to clarify what this bug is meant to be about. Is the goal that console.log from a panel work like from a webpage, or that it work like from an add-on's code?
Personally, I would say that for the documents loaded in Panel, Widget and Page Worker, we should have `console.log` working like from an add-on's code: it's more like the "Global Console" we're talking about, because is logging in the terminal / Error Console during the development, and just in the Error Console (that is not bound to any tab) when is installed as XPI.

However, I'm a bit unease to inject and replace our console in a web document loaded in a panel, page worker or widget: that's because, as far as I know, our console doesn't implement all the methods implemented by a "regular" `console` object you can have in the web page (see https://developer.mozilla.org/en-US/docs/DOM/console), it's just for logging.

If we decided to go in that way, we should implements all the method a web page could expects from a `console` object.
(In reply to Dave Townsend (:Mossop) from comment #11)
> Just want to clarify what this bug is meant to be about. Is the goal that
> console.log from a panel work like from a webpage, or that it work like from
> an add-on's code?

What makes sense to me is that it would print to the global console, like we currently do from an add-on's code. A panel is not tab-specific.
Attachment #701199 - Flags: review?(rFobic)
Attachment #701199 - Flags: review?(rFobic) → review+
Attachment #701199 - Flags: review+ → review?(poirot.alex)
Comment on attachment 701199 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/722#attch-to-bugzilla

The only thing that stress me is this bind issue:
https://github.com/mozilla/addon-sdk/pull/722/files#r2744145

Otherwise we will most likely do a followup in order to clean exposedProps.
We can also do a followup in order to attach console object earlier.
Attachment #701199 - Flags: review?(poirot.alex) → review+
Bobby, we are having some doubt about the usage of __exposedProps__  in consoleAPI.js. Could you confirm that when use Cu.createObjectIn, we no longer need to set __exposedProps__?
If that's the case, I think that Blake forgot to remove it when he started using createObjectIn in this patch:
https://bugzilla.mozilla.org/show_bug.cgi?id=634156#attach_539856

I'm speaking about that __exposedProps__:
http://hg.mozilla.org/mozilla-central/annotate/e9f39220b8e7/dom/base/ConsoleAPI.js#l132
Commits pushed to master at https://github.com/mozilla/addon-sdk

https://github.com/mozilla/addon-sdk/commit/d55e24d535097dbf061ad5963760cf20de2ff935
Bug 731074 - console.log not working from a panel's script

- Added web console methods to plain-text console
- Added plain-text console to web pages in documents not in a tab
- Updated unit test

https://github.com/mozilla/addon-sdk/commit/a4df0ded9e378ef18632fe0ffc30118dddadb560
Merge pull request #722 from ZER0/panel-console/731074

Fix Bug 731074 - console.log not working from a panel's script r=@Gozala, @ochameau
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to Alexandre Poirot (:ochameau) from comment #17)
> Bobby, we are having some doubt about the usage of __exposedProps__  in
> consoleAPI.js. Could you confirm that when use Cu.createObjectIn, we no
> longer need to set __exposedProps__?

Yeah, __exposedProps__ only has any meaning for objects that live in chrome scopes.
Great, thanks Bobby, so we can safely remove the `__exposedProps__` then. That is meaning that `__exposedProps__` in `ConsoleAPI` is a left-over, right?
No longer blocks: 841497
You need to log in before you can comment on or make changes to this bug.