Changes to the 'console' object in Firebug 1.2

[John J Barton]

Firebug 1.2 will require users of the 'console' object, as in
console.log() etc, to issue
loadFirebugConsole()
before the first use of the 'console' object. Since you are going to
hate this anyway, what do you think about also changing the name of
the 'console' object, eg 'fbConsole' or firebug.console or other ways
to reduce potential collisions?

See also:http://code.google.com/p/fbug/issues/detail?id=109

John.

[Zacky Ma]

I think fb.console is acceptable...

--
Zacky MA
www.marchbox.com

[Jan Odvarko]

I definitely like the idea of having single namespace with all
Firebug's services attached. Even if this breaks backward
compatibility I would do it rather sooner than later (I think
it's actually a must).

I don't have strong opinion on this, but I would prefer "firebug" as
the name so, e.g. firebug.console

Honza

[Mark Kahn]

I think that if this is going to be done I'd prefer "firebug", "fireBug" or "Firebug" to be the namespace, preferably the first one.  Why does loadFirebugConsole() need to be called?  Couldn't you do something like:

firebug.console = function(){
   loadFirebugConsole();
   firebug.console = firebug._console;
   firebug.console.call(this, arguments);
}

firebug._console = function(){ // real function }

Adding a namespace is one thing, requiring another call is another.  One of the great things about firebug is that I can just type "console.log" anywhere  :-)


As for the bug that was filed, arguing that Safari has its own console object is just rediculous.  Firebug is a firefox-specific extension and any calls to firebug in code NEED to be removed before the code is made live.  The argument boils down to "Well I need to remove console for IE, Opera and any other browser, but I don't want to remove it for safari"...???


I wonder how many people, besides myself, are going to be forced to write:

if(window.firebug){
   window.console = firebug.console;
   window.trace = firebug.trace;
   // etc
}

Could you please make sure that these will work?  :-)

-Mark

[John J Barton]

On Apr 2, 10:45 am, "Mark Kahn" <cwol...@gmail.com> wrote:
> I think that if this is going to be done I'd prefer "firebug", "fireBug" or
> "Firebug" to be the namespace, preferably the first one. Why does
> loadFirebugConsole() need to be called? Couldn't you do something like:
>
> firebug.console = function(){
> loadFirebugConsole();
> firebug.console = firebug._console;
> firebug.console.call(this, arguments);
>
> }

The line
firebug.console = firebug._console;
will cause infinite recursion, calling your function again (assuming
you meant to define a getter rather than a function).

John

[John J Barton]

On Apr 2, 11:49 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> On Apr 2, 10:45 am, "Mark Kahn" <cwol...@gmail.com> wrote:
>
> > I think that if this is going to be done I'd prefer "firebug", "fireBug" or
> > "Firebug" to be the namespace, preferably the first one. Why does
> > loadFirebugConsole() need to be called? Couldn't you do something like:
>
> > firebug.console = function(){
> > loadFirebugConsole();
> > firebug.console = firebug._console;
> > firebug.console.call(this, arguments);
>
> > }

Sorry I should say...I tried that so I know that:

[Mark Kahn]

Unless running it via a plugin changes the functionality:

<script>
function loadFirebugConsole(){
    alert('loadFirebugConsole');
    // do stuff here
}

var firebug = {};
firebug.console = {
    init: function(){
        loadFirebugConsole();
        firebug.console = firebug._console;
    },
    log: function(){
        this.init();
        firebug.console.log.apply(this, arguments);
    }
};
firebug._console = {
    log: function(){
        alert('real console.log called with '+arguments.length+' arguments: 1:'+arguments[0]);
    }
};

firebug.console.log('this is a test');
</script>

-Mark

[John J Barton]

Yes, but you can't add the script to the page because you can't get
control after the document is valid but before any javascript (which
could use the console) can run. For example, if the first tag in the
page is <script> console.log('ff'): ...

You can eval an object or function, but the environment will be
evalInSandbox, so you won't have the same Javascript world as the
page. So you can't load the whole console, just a loader to do it
later.

So that leaves you with needing a function call to trigger the "do it
later" bit.

It could be "loadFirebugConsole()" as I propose. Or it could be
window.console using a getter method. I guess it could be
firebug.__defineGetter__("console", function() {

}

On Apr 2, 12:44 pm, "Mark Kahn" <cwol...@gmail.com> wrote:
> Unless running it via a plugin changes the functionality:
>
> <script>
> function loadFirebugConsole(){
> alert('loadFirebugConsole');
> // do stuff here
>
> }
>
> var firebug = {};
> firebug.console = {
> init: function(){
> loadFirebugConsole();
> firebug.console = firebug._console;
> },
> log: function(){
> this.init();
> firebug.console.log.apply(this, arguments);
> }};
>
> firebug._console = {
> log: function(){
> alert('real console.log called with '+arguments.length+' arguments:
> 1:'+arguments[0]);
> }
>
> };
>
> firebug.console.log('this is a test');
> </script>
>
> -Mark
>

> On Wed, Apr 2, 2008 at 12:12 PM, John J Barton <johnjbar...@johnjbarton.com>

[Mark Kahn]

I guess I'm confused as to why the loadFirebugConsole function is suddenly needed when it never has been before?

-Mark

[John J Barton]

On Apr 2, 1:11 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Yes, but you can't add the script to the page because you can't get
> control after the document is valid but before any javascript (which
> could use the console) can run. For example, if the first tag in the
> page is <script> console.log('ff'): ...
>
> You can eval an object or function, but the environment will be
> evalInSandbox, so you won't have the same Javascript world as the
> page. So you can't load the whole console, just a loader to do it
> later.
>
> So that leaves you with needing a function call to trigger the "do it
> later" bit.
>
> It could be "loadFirebugConsole()" as I propose. Or it could be
> window.console using a getter method. I guess it could be
> firebug.__defineGetter__("console", function() {

if (firebug._console) return firebug._console;
firebug._console = loadFirebugConsole();
}

[John J Barton]

Because of changes in the way extensions interact with web pages in
FF3.

On Apr 2, 1:15 pm, "Mark Kahn" <cwol...@gmail.com> wrote:
> I guess I'm confused as to why the loadFirebugConsole function is suddenly
> needed when it never has been before?
>
> -Mark
>

> On Wed, Apr 2, 2008 at 1:11 PM, John J Barton <johnjbar...@johnjbarton.com>

[Mark Kahn]

so it's a planned change in FF3 that hasn't been implemented?  Or it has been and they're just allowing backwards compatibility till FF3 is actually launched?  Cause firebug works now in FF3 without loadFirebugConsole  :-)

It also seems weird that you'd be able to call one function but not another...why would loadFirebugConsole work if firebug.console.log wouldn't?

Sorry, I don't mean to sound arrogant or anything, I'm just curious as to what's going on here  :-)

-Mark

[John J Barton]

The functions will be added in evalInSandbox. If I load all of the
console that way the console won't work because the compilation scope
of evalInSandbox is missing stuff. So I have to use a
loadFirebugConsole(), running in the scope of the page, to later load
firebug.console.

Have you tried FF3b5 with Firebug 1.1 command line? You should see
http://code.google.com/p/fbug/issues/detail?id=512

But I'll look in to the getter. If that works you can forget all about
loadFirebugConsole()

On Apr 2, 1:45 pm, "Mark Kahn" <cwol...@gmail.com> wrote:
> so it's a planned change in FF3 that hasn't been implemented? Or it has
> been and they're just allowing backwards compatibility till FF3 is actually
> launched? Cause firebug works now in FF3 without loadFirebugConsole :-)
>
> It also seems weird that you'd be able to call one function but not
> another...why would loadFirebugConsole work if firebug.console.log wouldn't?
>
> Sorry, I don't mean to sound arrogant or anything, I'm just curious as to
> what's going on here :-)
>
> -Mark
>

> On Wed, Apr 2, 2008 at 1:27 PM, John J Barton <johnjbar...@johnjbarton.com>

[Travis Cline]

On Apr 2, 12:03 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Firebug 1.2 will require users of the 'console' object, as in
> console.log() etc, to issue
> loadFirebugConsole()

Is this for performance reasons?

-Travis

[Mark Kahn]

In that case couldn't you just do:

function loadFirebugConsole(){
  if(!this.loaded){ ...
}

firebug.console = {
   log: function(){
      loadFirebugConsole();
   }
}

-Mark

[PS]

There is also another problem: There are already a few sites out there
that overwrite the console object deliberately, to make inspection
harder. It's not really critical but can be annoying.
So couldn't you make it a toolbar button instead of a function? (or in
addition to). Something like "Load Firebug namespace". This would make
it easier to call and - because it's no programming command, would be
out of the way for any kind of collision.

[John J Barton]

The console object only helps code in the page report out to Firebug.
It has no role in inspection.

[John J Barton]

Ok, new proposal:

console.log("foo");

becomes

firebug.log("foo");

and

window.console = window.firebug; // legacy adaptor

To get from there to here. I've tested a version like this for 1.2 in
svn.

Comments?

[LiuCougar]

On Fri, Apr 4, 2008 at 6:00 PM, John J Barton
<johnj...@johnjbarton.com> wrote:
>
> Ok, new proposal:
>
> console.log("foo");
>
> becomes
>
> firebug.log("foo");
>
> and
>
> window.console = window.firebug; // legacy adaptor

I'd vote for doing this by default in firebug code.

after the introduction of console by firebug, it is widely adopted
(there are extensions for safari and IE to add console support, which
all mimic the API of the firebug console) (opera may have something
similar as well)

so IMO it is fine to keep it like that

>
> To get from there to here. I've tested a version like this for 1.2 in
> svn.
>
> Comments?
>
>
> >
>

--
生于忧患，死于安乐
"People's characters are strengthened through struggle against
difficulties; they are weakened by comfort."
- Old Chinese adage

[John J Barton]

On Apr 4, 10:28 am, LiuCougar <liucou...@gmail.com> wrote:

> On Fri, Apr 4, 2008 at 6:00 PM, John J Barton<johnjbar...@johnjbarton.com> wrote:
>
> > Ok, new proposal:
>
> > console.log("foo");
>
> > becomes
>
> > firebug.log("foo");
>
> > and
>
> > window.console = window.firebug; // legacy adaptor
>
> I'd vote for doing this by default in firebug code.
>
> after the introduction of console by firebug, it is widely adopted
> (there are extensions for safari and IE to add console support, which
> all mimic the API of the firebug console) (opera may have something
> similar as well)

Can you point to online information about this?

[Mark Kahn]

You've got it backwards.

Safari did it first, then Firebug then the IE Dom inspector plugin.

I still vote on leaving everything as is as polluting one variable that everyone knows about isn't a big deal!  And the Safari argument is utterly ridiculous :-).  But if you're going to switch I like this idea the best.

-Mark

[miken32]

I'd like to see things stay the same, and for you guys to get in touch
with the Safari/Webkit folks to have a consistent API across both
platforms. Your printf syntax for logging is far more usable, and of
course they don't support any of the other functions.

[Mark Kahn]

The point I was trying to make before is why bother trying to make them the same?  They're debugging tools, for crying out loud, they're not meant to be used across multiple browsers.  The simple fact that multiple browsers support the same call doesn't mean that they're the same thing.  If we rename the call to "firebug.log" or whatnot, you're STILL going to need seperate code between firefox & safari, the "firebug.log" call will trigger errors in safari and IE and everything else...what do you gain?

now:
console.log works in every browser, given the necessary plugins.  Granted, FB's implementation is far more robust than most, but you can still do basic things: console.log('foobar'); that will work in every browser.  If you try to use the printf syntax other browsers break?  Not sure, havn't tried in them.  I'm guessing you just won't get the replacements.

if changed:
console.log works in every browser except, possibly, FF.  firebug.log, or whatever it's changed to, works in FF.  So you now need to do MORE work to test in other browsers.

I just don't get the point of renaming it...I think the argument is "Oh, I need to remove the different console.log calls when I switch to other browsers", well you're going to need to do that NO MATTER WHAT if you use the FB printf syntax!

-Mark

[Mark Kahn]

putting this slightly differently:

right now the only thing that's cross-browser, AFAIK, is console.log(STRING).  This works exactly the same in every browser given that the proper tools are installed.

for ANYTHING else that FB offers, you NEED to remove those calls for those other browsers.  If we change the namespace, we're left with EXACTLY the same thing minus the console.log(STRING) functionality, and now console.log(STRING) works in every browser EXCEPT FF!

Am I really the only one that thinks this is crazy?!?

-Mark

[TheDoctorWhat]

I like "firebug" as the namespace. I think that having to explicitly
load the firebug stuff is great, despite all the people thinking
otherwise.

I'd prefer it something like loadFirebug() instead of 'console" in the
name, too.

Example usage:
try {
loadFirebug();
} catch (e) {
firebug = { log: function () {} };
}

firebug.log('blah');

Ciao!

[Mark Kahn]

I really don't want to pollute every page I ever write with:

try{
   loadFirebug();
}catch(e){
   firebug = {log: function(){}, debug: function(){}, info: function(){}, warn: function(){}, error: function(){}, assert: function(){}, dir: function(){}, dirxml: function(){}, trace: function(){}, group: function(){}, groupEnd: function(){}, time: function(){}, timeEnd: function(){}, profile: function(){}, profileEnd: function(){}, count: function(){}}
}

Not to mention keeping up with API changes and having to modify this call if I ever want to use future methods.  And how is this any better than:

if(!console){
   console = {log: function(){}, debug: function(){}, info: function(){}, warn: function(){}, error: function(){}, assert: function(){}, dir: function(){}, dirxml: function(){}, trace: function(){}, group: function(){}, groupEnd: function(){}, time: function(){}, timeEnd: function(){}, profile: function(){}, profileEnd: function(){}, count: function(){}}
}

???

[John J Barton]

I think there are reasonable arguments for "console" and for
"somethingObscure". For now I'll leave it as it has been ('console')
and move on.