Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: CordovaJS
    • Labels:
      None

      Description

      There is some room for improvement in the console object we support in Cordova.

      1. not all of the common API is supported. Here is the API as implemented by Firebug, most of which is also implemented in Web Inspector: Firebug Console API. An example of the issue with this is that the weinre demo makes use of markTimeline (actually, that's a WebKit-only console method - I think the only one!). So the demo dies an early death, if Cordova's console wins the "overwrite the native" battle.

      2. which naturally leads to the next issue - the console should daisy chain its calls to the "native" console, if it exists. An example of this issue is that if you use iWebInspector on a Cordova app, console logging happens in the Xcode console, not the iWebInspector console. I'm fine to have it in both places.

      3. console output operations should "buffer". An example of this issue is that any console operations which occur BEFORE deviceReady are passed directly to the bit bucket. Instead, we should "buffer" these, and then when deviceReady occurs, the console can dump what it's buffered.

      Turns out, I have some of these same issues in weinre, but I don't think we can share an implementation. weinre generally just delegates everything to the weinre client - eg, arguments to console.log() are sent as 'remote objects', whereas in Cordova we actually need to evaluate them. The buffering and daisy chaining should be exactly the same, and perhaps those need to be configured (eg, console.daisyChainNative(false)) - maybe the code or at least design could be shared there.

        Issue Links

          Activity

          Hide
          Drew Walters added a comment -

          The BlackBerry platform file currently does some crude daisy chaining of console.log which allows me to view log output on device as well as from web inspector on OS 7:
          https://github.com/apache/incubator-cordova-js/blob/master/lib/platform/blackberry.js

          Show
          Drew Walters added a comment - The BlackBerry platform file currently does some crude daisy chaining of console.log which allows me to view log output on device as well as from web inspector on OS 7: https://github.com/apache/incubator-cordova-js/blob/master/lib/platform/blackberry.js
          Hide
          Olivier Louvignes added a comment -

          This is very important and should be prioritized.

          I'm trying to get the log output into iWebInspector. Tried to add `this.winConsole.log(message);` befor the PhoneGap.exec call but it does not work (Phonegap 1.4.1), any ideas how to bring back this amazing tool to life?

          Show
          Olivier Louvignes added a comment - This is very important and should be prioritized. I'm trying to get the log output into iWebInspector. Tried to add `this.winConsole.log(message);` befor the PhoneGap.exec call but it does not work (Phonegap 1.4.1), any ideas how to bring back this amazing tool to life?
          Hide
          Patrick Mueller added a comment -

          A somewhat related topic is discussed in CB-387. Namely, how to report errors at a particular point in bootstrapping. In this case, we may not have a cordova object available, the console object may not be set up, etc.

          How this relates is at two-fold:

          1. We may want to present messages to facilities other than the console, if it's not actually available. For instance alert() may be available, but not console. Or, we might want to provide a way to add error messages to the DOM in a structured way: look for an element of class cordova-error-list, append a <li>> to it's children, set the cordova-error-messages-available class on the <body> element. This would allow someone to "embed" error messages in their app.

            Note, being overly general with the DOM injection version there, but if we're going to open this thing up, it would be nice to account for being able to do something like that in the future. Not sure there's a pressing need for this today.

          2. We should probably make this "inform the user in the best way" functionality available as a "plain old script" that we could inject into browser environment, for platforms that do such injections - like iOS. Reuse the code. Totally do-able, folks write "scripts" that can either be used as modules or treated like plain old scripts, all the time. See underscore.js.
          Show
          Patrick Mueller added a comment - A somewhat related topic is discussed in CB-387 . Namely, how to report errors at a particular point in bootstrapping. In this case, we may not have a cordova object available, the console object may not be set up, etc. How this relates is at two-fold: We may want to present messages to facilities other than the console , if it's not actually available. For instance alert() may be available, but not console . Or, we might want to provide a way to add error messages to the DOM in a structured way: look for an element of class cordova-error-list , append a <li>> to it's children, set the cordova-error-messages-available class on the <body> element. This would allow someone to "embed" error messages in their app. Note, being overly general with the DOM injection version there, but if we're going to open this thing up, it would be nice to account for being able to do something like that in the future. Not sure there's a pressing need for this today. We should probably make this "inform the user in the best way" functionality available as a "plain old script" that we could inject into browser environment, for platforms that do such injections - like iOS. Reuse the code. Totally do-able, folks write "scripts" that can either be used as modules or treated like plain old scripts, all the time. See underscore.js.
          Show
          Patrick Mueller added a comment - See also: CB-508 - better diagnostic capabilities for startup code CB-611 - Logging levels CB-613 - Fix console.log not sprintf'ing input content
          Show
          Patrick Mueller added a comment - See also: CB-612 - FAdd support for native remoteInspector logging
          Show
          Patrick Mueller added a comment - implemented console using logger in this commit: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commit;h=4c8c52f9c52e170c2f66648ea281d24f12cb27ef
          Hide
          Patrick Mueller added a comment -

          The current implementation of this issue is the lib/common/plugin/console-via-logger.js file, which is only useful if you are also using the logger plugin as the sink of the logging messages.

          We can do better, to provide a way for folks with lame-y console objects to be shimmed. Shimming means adding the methods in the FireBug/node.js console objects [1][2].

          Basic idea is to create a new module console-shims.js, which will support the following methods:

          installShims()

          Will create missing console methods which all use console.log() to generate the output.

          Calls removeShims() before installing the shims.

          installWrappedShims()

          Will create missing console methods which all use console.log() to generate the output,
          and for existing console methods, will call the original and then a 'shimmed' version which calls console.log()

          Calls removeShims() before installing the shims.

          removeShims()

          Resets the console object to the original version.

          installLoggerForConsole()

          Sets console.log() to call the original console.log(), if it exists, then logs the message with logger.log()

          For all platforms, we'll use:

              require("console-shims").installShims()
          

          For iOS, we'll use:

              require("console-shims").installLoggerForConsole()
              require("console-shims").installWrappedShims()
          

          And then of course other platforms can do whatever they wish.

          We can then do away with console-via-logger.js.

          [1] http://getfirebug.com/wiki/index.php/Console_API
          [2] http://nodejs.org/docs/latest/api/stdio.html

          Show
          Patrick Mueller added a comment - The current implementation of this issue is the lib/common/plugin/console-via-logger.js file, which is only useful if you are also using the logger plugin as the sink of the logging messages. We can do better, to provide a way for folks with lame-y console objects to be shimmed. Shimming means adding the methods in the FireBug/node.js console objects [1] [2] . Basic idea is to create a new module console-shims.js , which will support the following methods: installShims() Will create missing console methods which all use console.log() to generate the output. Calls removeShims() before installing the shims. installWrappedShims() Will create missing console methods which all use console.log() to generate the output, and for existing console methods, will call the original and then a 'shimmed' version which calls console.log() Calls removeShims() before installing the shims. removeShims() Resets the console object to the original version. installLoggerForConsole() Sets console.log() to call the original console.log() , if it exists, then logs the message with logger.log() For all platforms, we'll use: require("console-shims").installShims() For iOS, we'll use: require("console-shims").installLoggerForConsole() require("console-shims").installWrappedShims() And then of course other platforms can do whatever they wish. We can then do away with console-via-logger.js . [1] http://getfirebug.com/wiki/index.php/Console_API [2] http://nodejs.org/docs/latest/api/stdio.html
          Hide
          Patrick Mueller added a comment -

          per CB-773, make sure we do "something" non-throwy when we're provided with bogus input (eg, objects which cannot be JSON.stringify()'d).

          Show
          Patrick Mueller added a comment - per CB-773 , make sure we do "something" non-throwy when we're provided with bogus input (eg, objects which cannot be JSON.stringify() 'd).
          Hide
          Shazron Abdullah added a comment -

          Do we want to slate this for any upcoming Cordova version?

          Show
          Shazron Abdullah added a comment - Do we want to slate this for any upcoming Cordova version?
          Hide
          Patrick Mueller added a comment -

          I'm not so sure. Why there's a lot of improvement possible from where we
          are today, the other issue is that console is just generally wonky
          everywhere anyway, even on platforms with "first class support" for it. I
          was hoping we'd get some additional feedback over time directing us on the
          best course of action here. I think the lack of feedback we've gotten in
          general re: console (we've gotten some, but not much) is telling me the
          best course of action is to do nothing.

          The need for console methods may also be going away as the platforms start
          sprouting real debugger.

          But I'm game for anything.

          Show
          Patrick Mueller added a comment - I'm not so sure. Why there's a lot of improvement possible from where we are today, the other issue is that console is just generally wonky everywhere anyway, even on platforms with "first class support" for it. I was hoping we'd get some additional feedback over time directing us on the best course of action here. I think the lack of feedback we've gotten in general re: console (we've gotten some, but not much) is telling me the best course of action is to do nothing. The need for console methods may also be going away as the platforms start sprouting real debugger. But I'm game for anything.

            People

            • Assignee:
              Patrick Mueller
              Reporter:
              Patrick Mueller
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 256h
                256h
                Remaining:
                Remaining Estimate - 256h
                256h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development