I'm developing a remote XUL application and use console.log()
extensively. Today I upgraded my Firebug 1.1 installation to 1.2b1 and
now get a "console is not defined" error whenever the code hits a
console.log() call.
Within Firebug I can manually enter "console = _firebug;" to get
things working again - but that doesn't persist through a page
reload.
Based on a search of this group I've also tried calling
window.loadFirebugConsole() on my page, but that gives a "not a
function" error. From what I've read it shouldn't be necessary on Fx3
anyway.
I've tried disabling all my extensions, but that had no effect. I've
also tried opening Firefox with just a single HTML page (rather than
my remote XUL app), then calling console.log() within the console
itself, but that also gave the "console is not defined" error.
Have I missed something else that I need to do to initialise the
console on Fx3? If not, has anyone else experienced this issue and
found a workaround?
> I'm developing a remote XUL application and use console.log()
> extensively. Today I upgraded my Firebug 1.1 installation to 1.2b1 and
> now get a "console is not defined" error whenever the code hits a
> console.log() call.
> Within Firebug I can manually enter "console = _firebug;" to get
> things working again - but that doesn't persist through a page
> reload.
> Based on a search of this group I've also tried calling
> window.loadFirebugConsole() on my page, but that gives a "not a
> function" error. From what I've read it shouldn't be necessary on Fx3
> anyway.
> I've tried disabling all my extensions, but that had no effect. I've
> also tried opening Firefox with just a single HTML page (rather than
> my remote XUL app), then calling console.log() within the console
> itself, but that also gave the "console is not defined" error.
> Have I missed something else that I need to do to initialise the
> console on Fx3? If not, has anyone else experienced this issue and
> found a workaround?
Ah, that did the trick, but does leave me in a catch-22 situation: I'd
disabled script debugging because it was breaking the wizards in my
app. I filed this as an issue a little earlier today:
> In 1.2 the console is not added to the page unless you turn on Script
> debugging. Try that and let us know.
> On May 22, 6:35 am, Mark <mark.cru...@gmail.com> wrote:
> > I'm developing a remote XUL application and use console.log()
> > extensively. Today I upgraded my Firebug 1.1 installation to 1.2b1 and
> > now get a "console is not defined" error whenever the code hits a
> > console.log() call.
> > Within Firebug I can manually enter "console = _firebug;" to get
> > things working again - but that doesn't persist through a page
> > reload.
> > Based on a search of this group I've also tried calling
> > window.loadFirebugConsole() on my page, but that gives a "not a
> > function" error. From what I've read it shouldn't be necessary on Fx3
> > anyway.
> > I've tried disabling all my extensions, but that had no effect. I've
> > also tried opening Firefox with just a single HTML page (rather than
> > my remote XUL app), then calling console.log() within the console
> > itself, but that also gave the "console is not defined" error.
> > Have I missed something else that I need to do to initialise the
> > console on Fx3? If not, has anyone else experienced this issue and
> > found a workaround?
Philip, here are some choices:
Use FF3rc1 + Firebug 1.2. This is the combination we are focused on
for now.
Use FF2 + Firebug 1.1.
Use FF2 + Firebug 1.2 and add loadFirebugConsole() before you use
the console.
We will go back to FF2 with Firebug 1.2, but we can't do the same
solution for the console in both FF2 and FF3 I think.
On May 22, 11:06 am, Philip <sa...@altmuehlnet.de> wrote:
> It doesn't work for me. I've enabled the debugger for localhost but
> there's still no console available. I'm using Firefox 2.0.0.14.
> What can I do?
> On May 22, 4:38 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > In 1.2 the console is not added to the page unless you turn on Script
> > debugging. Try that and let us know.
> > On May 22, 6:35 am, Mark <mark.cru...@gmail.com> wrote:
> > > I'm developing a remote XUL application and use console.log()
> > > extensively. Today I upgraded my Firebug 1.1 installation to 1.2b1 and
> > > now get a "console is not defined" error whenever the code hits a
> > > console.log() call.
> > > Within Firebug I can manually enter "console = _firebug;" to get
> > > things working again - but that doesn't persist through a page
> > > reload.
> > > Based on a search of this group I've also tried calling
> > > window.loadFirebugConsole() on my page, but that gives a "not a
> > > function" error. From what I've read it shouldn't be necessary on Fx3
> > > anyway.
> > > I've tried disabling all my extensions, but that had no effect. I've
> > > also tried opening Firefox with just a single HTML page (rather than
> > > my remote XUL app), then calling console.log() within the console
> > > itself, but that also gave the "console is not defined" error.
> > > Have I missed something else that I need to do to initialise the
> > > console on Fx3? If not, has anyone else experienced this issue and
> > > found a workaround?
> In 1.2 the console is not added to the page unless you turn on Script
> debugging. Try that and let us know.
> On May 22, 6:35 am, Mark <mark.cru...@gmail.com> wrote:
> > I'm developing a remote XUL application and use console.log()
> > extensively. Today I upgraded my Firebug 1.1 installation to 1.2b1 and
> > now get a "console is not defined" error whenever the code hits a
> > console.log() call.
> > Within Firebug I can manually enter "console = _firebug;" to get
> > things working again - but that doesn't persist through a page
> > reload.
> > Based on a search of this group I've also tried calling
> > window.loadFirebugConsole() on my page, but that gives a "not a
> > function" error. From what I've read it shouldn't be necessary on Fx3
> > anyway.
> > I've tried disabling all my extensions, but that had no effect. I've
> > also tried opening Firefox with just a single HTML page (rather than
> > my remote XUL app), then calling console.log() within the console
> > itself, but that also gave the "console is not defined" error.
> > Have I missed something else that I need to do to initialise the
> > console on Fx3? If not, has anyone else experienced this issue and
> > found a workaround?
Actually I had another idea to suggest that also would address another
posters issue with 1.2.
What if we made the Console tabs also activatible?
By default three tabs would be "off" Console, Script, Net.
Console would control
1) injection of console object in page, (not script panel)
2) error message tracking (current always on)
3) XMLHTTPRequest logging (controlled by Console->options).
+ Reach the zero-overhead goal of 1.2 (we miss on XMLHTTPRequest
logging and error tracking now)
+ console.log() without script panel activation
+ direct visibility of optional state (gray tab names mean off)
+ fine control over performance
- now three controls for full firebug enable, tedious for those who
want it all. (which is why we rejected the idea before).
- more work to code it.
To address three-controls issue we could introduce an enablement-
linking preference that remembers the set of enabled panels for a user
and restore that set when any panel from the set is enabled. This is
aimed a habitual use, not exploratory use. For examples:
John enables Console, Script, and Net on page A. Later he opens
page B and enables Script. The other two are enabled also.
Sue enables Console and Net on page C. Later she opens page D and
enables Console. Net will also be enabled. She disables Net. Later she
opens page E and enables Console. No other enablement.
Is it clear? Does it make sense?
On May 23, 4:37 am, Jan Odvarko <odva...@gmail.com> wrote:
I like the idea of having the Console activatible independently of the
Script tab, but I think the linking preference is over complicating
matters. How about simply being able to switch any/all of them on or
off from the "En/Disable" menu of any one of them.
In other words, whichever tab is currently showing has its own "Enable
this for domain" button as it does now, but the "Disabled" menu would
contain the following:
* Enable console for domain
* Enable debugger for domain
* Enable monitor for domain
----------------------
* Enable all for domain
* Disable all for domain
The first three would either have checkmarks and/or change their text
to "Disable blah for domain" when they're enabled. The bottom options
just enable or disable all three options at once.
This way a developer can enable any combination of panels they wish,
but without the need to actually switch between the panels to do so.
In the case of one or three panels needing to be enabled, one visit to
the menu will do it. For two panels it needs two visits to the menu.
In either case it's no worse (and probably better) than the current
method of visiting two panels to activate both Script and Net.
On May 23, 4:32 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Actually I had another idea to suggest that also would address another
> posters issue with 1.2.
> What if we made the Console tabs also activatible?
> By default three tabs would be "off" Console, Script, Net.
> Console would control
> 1) injection of console object in page, (not script panel)
> 2) error message tracking (current always on)
> 3) XMLHTTPRequest logging (controlled by Console->options).
> + Reach the zero-overhead goal of 1.2 (we miss on XMLHTTPRequest
> logging and error tracking now)
> + console.log() without script panel activation
> + direct visibility of optional state (gray tab names mean off)
> + fine control over performance
> - now three controls for full firebug enable, tedious for those who
> want it all. (which is why we rejected the idea before).
> - more work to code it.
> To address three-controls issue we could introduce an enablement-
> linking preference that remembers the set of enabled panels for a user
> and restore that set when any panel from the set is enabled. This is
> aimed a habitual use, not exploratory use. For examples:
> John enables Console, Script, and Net on page A. Later he opens
> page B and enables Script. The other two are enabled also.
> Sue enables Console and Net on page C. Later she opens page D and
> enables Console. Net will also be enabled. She disables Net. Later she
> opens page E and enables Console. No other enablement.
A variation of this idea would not use the pull down menu (leave it as
is), but put multiple buttons on the Disabled Panel that comes up when
the script/net/console tab is disabled but selected. Then enable all
or two or one would be "select a disabled panel", click a button.
On May 23, 8:53 am, Mark <mark.cru...@gmail.com> wrote:
> I like the idea of having the Console activatible independently of the
> Script tab, but I think the linking preference is over complicating
> matters. How about simply being able to switch any/all of them on or
> off from the "En/Disable" menu of any one of them.
> In other words, whichever tab is currently showing has its own "Enable
> this for domain" button as it does now, but the "Disabled" menu would
> contain the following:
> * Enable console for domain
> * Enable debugger for domain
> * Enable monitor for domain
> ----------------------
> * Enable all for domain
> * Disable all for domain
> The first three would either have checkmarks and/or change their text
> to "Disable blah for domain" when they're enabled. The bottom options
> just enable or disable all three options at once.
> This way a developer can enable any combination of panels they wish,
> but without the need to actually switch between the panels to do so.
> In the case of one or three panels needing to be enabled, one visit to
> the menu will do it. For two panels it needs two visits to the menu.
> In either case it's no worse (and probably better) than the current
> method of visiting two panels to activate both Script and Net.
> On May 23, 4:32 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > Actually I had another idea to suggest that also would address another
> > posters issue with 1.2.
> > What if we made the Console tabs also activatible?
> > By default three tabs would be "off" Console, Script, Net.
> > Console would control
> > 1) injection of console object in page, (not script panel)
> > 2) error message tracking (current always on)
> > 3) XMLHTTPRequest logging (controlled by Console->options).
> > + Reach the zero-overhead goal of 1.2 (we miss on XMLHTTPRequest
> > logging and error tracking now)
> > + console.log() without script panel activation
> > + direct visibility of optional state (gray tab names mean off)
> > + fine control over performance
> > - now three controls for full firebug enable, tedious for those who
> > want it all. (which is why we rejected the idea before).
> > - more work to code it.
> > To address three-controls issue we could introduce an enablement-
> > linking preference that remembers the set of enabled panels for a user
> > and restore that set when any panel from the set is enabled. This is
> > aimed a habitual use, not exploratory use. For examples:
> > John enables Console, Script, and Net on page A. Later he opens
> > page B and enables Script. The other two are enabled also.
> > Sue enables Console and Net on page C. Later she opens page D and
> > enables Console. Net will also be enabled. She disables Net. Later she
> > opens page E and enables Console. No other enablement.
You go to the Console tab, click "Enable Console" button... and then
the remaining buttons get replaced with the content of the console.
You would either have to ensure that the current tab is the last
button you click, or rather than buttons you would need checkboxes and
an "Apply" button.
By using the menu things are kept simpler for people who just want to
enable one panel (probably the Console) as they never need to see the
complexity, they just click the one button they can see.
But whatever the UI, I certainly think that having the console.*()
calls tied to enabling the Console panel rather than the Script panel
makes a lot of sense.
On May 23, 5:20 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> A variation of this idea would not use the pull down menu (leave it as
> is), but put multiple buttons on the Disabled Panel that comes up when
> the script/net/console tab is disabled but selected. Then enable all
> or two or one would be "select a disabled panel", click a button.
I also welcome the idea of having activable Console panel!
I was considering it too and it looks like the logical way that
nicely solves all the mentioned problems with Console tab.
As far as the problem of "Enable all panels at once" is concerned,
I like Mark's proposal to have a menu with options like as follows:
* Enable console for domain
* Enable debugger for domain
* Enable monitor for domain
----------------------
* Enable all for domain
* Disable all for domain
At the same time, I agree with John that these options don't have to
be
necessarily part of the "Disable" menu. The power of this menu is the
simplicity
(it's just "enable for the site" and "disable") and further, the menu
is attached to
a specific panel. So, e.g. in case of the Net panel, it could be mess
if there are
options related to the other panels.
However it makes excellent fit, if the menu would be a context menu
attached to the FB's tab bar. In such a case the user could enable/
disable any panel by just right clicking on its tab an choosing enable
from its context menu - without necessity to actually activate the
tab. And of course, the plus would be additional items like "Enable
all for domain" and "Disable all for domain".
I also think that the menu doesn't have to show list of all the
"activable" tabs all the time - only the clicked one could be
displayed. So, the menu would be like as follows (in the case when
disabled Console tab would be right-clicked):
* Enable Console for domain
----------------------
* Enable all for domain
* Disable all for domain
Sure, "Enable console for domain" would change to "Disable console for
domain" if Console is currently enabled.
What do you think?
Honza
On May 23, 6:38 pm, Mark <mark.cru...@gmail.com> wrote:
> You go to the Console tab, click "Enable Console" button... and then
> the remaining buttons get replaced with the content of the console.
> You would either have to ensure that the current tab is the last
> button you click, or rather than buttons you would need checkboxes and
> an "Apply" button.
> By using the menu things are kept simpler for people who just want to
> enable one panel (probably the Console) as they never need to see the
> complexity, they just click the one button they can see.
> But whatever the UI, I certainly think that having the console.*()
> calls tied to enabling the Console panel rather than the Script panel
> makes a lot of sense.
> On May 23, 5:20 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > A variation of this idea would not use the pull down menu (leave it as
> > is), but put multiple buttons on the Disabled Panel that comes up when
> > the script/net/console tab is disabled but selected. Then enable all
> > or two or one would be "select a disabled panel", click a button.
One more addition. I have already proposed (in another discussion,
but it's related to the the Console too) to have another option
in "Options" menu that would make possible to enable-always
specific activable tab.
So, if such an option would be checked for the Console panel -
it would be enabled by default for every site.
Opinions?
Honza
On May 26, 11:18 am, Jan Odvarko <odva...@gmail.com> wrote:
> I also welcome the idea of having activable Console panel!
> I was considering it too and it looks like the logical way that
> nicely solves all the mentioned problems with Console tab.
> As far as the problem of "Enable all panels at once" is concerned,
> I like Mark's proposal to have a menu with options like as follows:
> * Enable console for domain
> * Enable debugger for domain
> * Enable monitor for domain
> ----------------------
> * Enable all for domain
> * Disable all for domain
> At the same time, I agree with John that these options don't have to
> be
> necessarily part of the "Disable" menu. The power of this menu is the
> simplicity
> (it's just "enable for the site" and "disable") and further, the menu
> is attached to
> a specific panel. So, e.g. in case of the Net panel, it could be mess
> if there are
> options related to the other panels.
> However it makes excellent fit, if the menu would be a context menu
> attached to the FB's tab bar. In such a case the user could enable/
> disable any panel by just right clicking on its tab an choosing enable
> from its context menu - without necessity to actually activate the
> tab. And of course, the plus would be additional items like "Enable
> all for domain" and "Disable all for domain".
> I also think that the menu doesn't have to show list of all the
> "activable" tabs all the time - only the clicked one could be
> displayed. So, the menu would be like as follows (in the case when
> disabled Console tab would be right-clicked):
> * Enable Console for domain
> ----------------------
> * Enable all for domain
> * Disable all for domain
> Sure, "Enable console for domain" would change to "Disable console for
> domain" if Console is currently enabled.
> What do you think?
> Honza
> On May 23, 6:38 pm, Mark <mark.cru...@gmail.com> wrote:
> > How would multiple buttons work though?
> > You go to the Console tab, click "Enable Console" button... and then
> > the remaining buttons get replaced with the content of the console.
> > You would either have to ensure that the current tab is the last
> > button you click, or rather than buttons you would need checkboxes and
> > an "Apply" button.
> > By using the menu things are kept simpler for people who just want to
> > enable one panel (probably the Console) as they never need to see the
> > complexity, they just click the one button they can see.
> > But whatever the UI, I certainly think that having the console.*()
> > calls tied to enabling the Console panel rather than the Script panel
> > makes a lot of sense.
> > On May 23, 5:20 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > A variation of this idea would not use the pull down menu (leave it as
> > > is), but put multiple buttons on the Disabled Panel that comes up when
> > > the script/net/console tab is disabled but selected. Then enable all
> > > or two or one would be "select a disabled panel", click a button.
|
