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)
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)?
Reporter | ||
Comment 1•12 years ago
|
||
(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.
Comment 2•12 years ago
|
||
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.
Comment 3•12 years ago
|
||
Alex, do you want to reach out to the devtools guys if we need any help here?
Priority: -- → P2
Comment 4•12 years ago
|
||
Should this be a P1? It's a pretty surprising result, and makes debugging panel code really hard.
Comment 5•12 years ago
|
||
Seems a little surprising to me too, let's talk about it in next triage.
Priority: P2 → --
Reporter | ||
Updated•12 years ago
|
Priority: -- → P1
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → zer0
Comment 6•11 years ago
|
||
(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.
Comment 7•11 years ago
|
||
(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.
Comment 8•11 years ago
|
||
(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.
Comment 9•11 years ago
|
||
(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.
Comment 10•11 years ago
|
||
(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.
Comment 11•11 years ago
|
||
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?
Assignee | ||
Comment 12•11 years ago
|
||
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.
Comment 13•11 years ago
|
||
(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.
Assignee | ||
Comment 14•11 years ago
|
||
Pointer to Github pull-request
Assignee | ||
Comment 15•11 years ago
|
||
Pointer to Github pull-request
Assignee | ||
Updated•11 years ago
|
Attachment #701199 -
Flags: review?(rFobic)
Updated•11 years ago
|
Attachment #701199 -
Flags: review?(rFobic) → review+
Assignee | ||
Updated•11 years ago
|
Attachment #701199 -
Flags: review+ → review?(poirot.alex)
Comment 16•11 years ago
|
||
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+
Comment 17•11 years ago
|
||
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
Comment 18•11 years ago
|
||
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
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 19•11 years ago
|
||
(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.
Assignee | ||
Comment 20•11 years ago
|
||
Great, thanks Bobby, so we can safely remove the `__exposedProps__` then. That is meaning that `__exposedProps__` in `ConsoleAPI` is a left-over, right?
Blocks: 841497
You need to log in
before you can comment on or make changes to this bug.
Description
•