Unable to disable

[badllama77]

I have set the disable options on all the panels that I can in 1.2.0b7
and it doesn't seem to be working. I went to maps. google.com and
received an error. So I added it to the sites list with a disabled
setting for each panel. I noticed that the icon in the corner is not
turning gray, am I missing something?

[Jim Stoner]

Hi,

I'm not sure. I really dislike that they took away the option of
disabling Firebug entirely from the context menu of the bug icon in
the status bar (or the Tools menu, for that matter). I do NOT want to
have to enable/disable each tab for each server individually. That's
just horrible, IMO. I want to be able to disable Firebug entirely
when I'm just browsing, and then easily enable it again when I need to
troubleshoot a page. That worked great in FF2, but when I installed
FF3 and upgraded to the most recent Firebug, I was disappointed with
that change.

Does anyone have any suggestions for how to easily disable and re-
enable Firebug in FF3? Is there a trick to it, other than doing it
tab-by-tab for each and every server? Is there another add-on that
will do it?

Any chance the developer(s) will put the Disable Firebug / Enable
Firebug back, preferably in the status bar icon context menu but at
least in the Tools menu?

Thanks!
Jim Stoner

[John J Barton]

Try this:
Set all the tabs (Console, Scripts, Net) back to 'disable'.
When you want to use Firebug on a site, enable the tabs you want for
that site.

One confusing aspect is the default: for Firebug 1.0 and 1.1 it was
"on by default". So lots of folks want to "disable by site".

For 1.2, it's disabled by default. So "disable by site" is not
important. Now you need to enable specific sites.

We are considering a status bar context menu, but we just don't know
what it should do. Having it set "disable for site" hardly makes sense
when the default is already "disable for site".

HTH,
John

[ScroogeMcPump]

On Jul 29, 1:53 am, John J Barton <johnjbar...@johnjbarton.com> wrote:

> Now you need to enable specific sites.

From other comments, it appears that the complaint being filed by
these people is that "Enable for this site" isn't living up to its
name, and is instead acting like "Enable for this site as well as any
others that happen to be open in other tabs at the same time as this
site, regardless of whether those others are actually on the same site
or not".

Enabling Firebug ungrays the bug (and slows down browsing) for ALL
tabs - not just the one you're working on, not just others from the
same site or others with the Firebug pane open, but all of them. Is
this the intended behavior? Maybe it is - maybe there's no way to put
that fine of a point on it - but if so, it should be made clearer in
the UI; maybe a extra blurb saying "You have tabs open from other
sites for which Firebug is disabled. Enabling Firebug for this site
will affect those other tabs as well, until you either close all tabs
for Firebug-enabled sites, or disable Firebug for all open sites. Do
you still want to do this?"

[John J Barton]

Well users figured out in earlier versions that they needed to disable
for site. There was no big popup telling folks to disable for site.
Requiring users to disable a tool for sites seems a bit odd doesn't
it? Yet users learned to do this.

I think a list of tabs in the status icon that cause FIrebug to be on
will help.

[Jim Stoner]

> Try this:
> Set all the tabs (Console, Scripts, Net) back to 'disable'.
> When you want to use Firebug on a site, enable the tabs you want for
> that site.

I guess my concern with that approach is that it is annoyingly slow to
do that every day. Opening it, going to the tab, clicking the drop
down button for that tab, selecting disable, going to the next tab,
rinse and repeat two more times. At least when it comes to enabling
Firebug for a site you can do it on one panel, although you still need
to check individual boxes for each of the tabs you want to work.

I guess I just don't want that much flexibility. I'd be happy to have
Firebug either on (with all tabs active) or off (with all tabs off).
That's it. Right click on the bug icon in the status bar, and toggle
between the two states. If Firebug is active, then the context menu
says "Disable Firebug". If Firebug is disabled, then the context menu
says "Enable Firebug".

If people want the option to enable/disable Firebug on a server-by-
server basis, then it could be "Enable for this server" (if currently
disabled), or "Disable for this server" (if currently active).

Heck, if people really want tab-by-tab / server-by-server options, you
could still let people set it the way they do now, but I'd still
advocate having a global "turn all off" or "turn all on" option in the
context menu of the status bar icon. That is just so much more user
friendly for people who do not need or want to select it on a tab-by-
tab / server-by-server basis.

Just my opinion, of course. :-)
Jim Stoner

On Jul 29, 1:53 am, John J Barton <johnjbar...@johnjbarton.com> wrote:

[John J Barton]

On Jul 29, 12:13 pm, Jim Stoner <jim.sto...@esc.edu> wrote:
> > Try this:
> > Set all the tabs (Console, Scripts, Net) back to 'disable'.
> > When you want to use Firebug on a site,  enable the tabs you want for
> > that site.
>
> I guess my concern with that approach is that it is annoyingly slow to
> do that every day.  Opening it, going to the tab, clicking the drop

You should only have to disable one time and the preference will be
remembered.

> down button for that tab, selecting disable, going to the next tab,
> rinse and repeat two more times.  At least when it comes to enabling
> Firebug for a site you can do it on one panel, although you still need
> to check individual boxes for each of the tabs you want to work.

And after that the pref sticks. I have been thinking about making the
check boxes all be selected by default, so the result would be very
close to previous Firebug (open then activiate).

>
> I guess I just don't want that much flexibility.  I'd be happy to have
> Firebug either on (with all tabs active) or off (with all tabs off).
> That's it.  Right click on the bug icon in the status bar, and toggle
> between the two states.  If Firebug is active, then the context menu
> says "Disable Firebug".  If Firebug is disabled, then the context menu
> says "Enable Firebug".

Unfortunately there are more than two states.

The underlying listeners need to be active during page loads. So if
the user starts up Firefox, visits some sites, then turns on Firebug
and visits some sites, do we show "Disable" ? or "enable"? Or "On"?

If the user turns Firebug "on", what do we do about the current tabs?
Leave them, and hope the user realizes that only part of the function
of FIrebug is available? Reload them all so that the "On" state is
correctly reflected in the UI? Reload the top page?

I think part of these issues have to do with habits. I don't think
people realize that in earlier Firebug versions they had to enable the
page then manually reload it. They just did that a few times and now
they think it is easy.

To be honest we have gotten a lot of feedback of the form "make it
simpler" but once the reality of the issues comes up, then we don't
get practical suggestions. Or maybe I'm not listening for them.

>
> If people want the option to enable/disable Firebug on a server-by-

> erver basis, then it could be "Enable for this server" (if currently
> disabled), or "Disable for this server" (if currently active).

The key dynamic here is that the Scripts tab takes a lot of overhead
and it is not needed by a large fraction of the user population. The
Net tab takes a lot of resource on some kinds of sites. That is why
we went with the individual controls.

>
> Heck, if people really want tab-by-tab / server-by-server options, you
> could still let people set it the way they do now, but I'd still
> advocate having a global "turn all off" or "turn all on" option in the
> context menu of the status bar icon.  That is just so much more user
> friendly for people who do not need or want to select it on a tab-by-
> tab / server-by-server basis.

Ok, I agree, but now to the details. If the user has
Console enable
Scripts disable
Net enable for this site
and the use selects "Turn all ON" what do you want the outcome to be?

[Jim Stoner]

> You should only have to disable one time and the preference will be
> remembered.

That assumes you always want it the same way on that server all the
time. If I work on a server all day with some of my time doing
development and some time for normal usage, I either have to have
Firebug enabled all the time for that server (which slows page loads
noticeably when doing normal usage), or turn it all on manually before
developing and then off again afterward. Turning it on isn't a
problem, but turning them off again gets annoying, doing it tab-by-
tab. It's not a huge problem or anything, it's just annoying compared
to the old approach of enabling/disabling Firebug globally.

> I have been thinking about making the
> check boxes all be selected by default, so the result would be very
> close to previous Firebug (open then activiate).

That would help, but it would also be nice to have a simple way to
deactivate too. Deactivating is much more annoying than activating
currently.

> If the user turns Firebug "on", what do we do about the current tabs?
> Leave them, and hope the user realizes that only part of the function
> of FIrebug is available? Reload them all so that the "On" state is
> correctly reflected in the UI? Reload the top page?

Personally, I'd think "leave them" is the right choice. As a user, if
I turn on new functionality after a page has loaded, I don't expect it
to magically apply to the old content. I would expect to have to
manually refresh it. At most, you could pop up an alert box reminding
them of that. Auto-refreshing it has the major disadvantage of not
knowing what frame to reload. There are a lot of sites where auto-
reloading the top page will actually navigate away from the displayed
content because the URL for the top page isn't related to displayed
content in embedded frames or framesets. I'd say it would be best for
the user to chose how/what to reload.

This brings up a side question I had. If I recall correctly, in older
versions of Firebug, it was either all enabled or all disabled. The
new version is always "partially enabled" in that the HTML, CSS and
DOM tabs are always active. Isn't that causing a performance hit on
every page?

Assuming there is a performance hit to the three always-on tabs, an
alternative approach to the "enable/disable" discussion would be to
literally enable or disable firebug as a whole. If Firebug is
disabled, then all those page listeners you mentioned go away and
there is no performance impact at all (but the HTML, CSS and DOM tabs
don't work then either). Then you enable Firebug and it works just
like it does now, with HTML, CSS and DOM always there and Console,
Script and Net configured on a server by server basis like it is in
the current version.

Then you would have a simple toggle in the status bar icon's context
menu: "Turn Firebug Off" would disable it entirely, no tabs at all,
no listeners, the Firebug panel won't open. "Turn Firebug On" would
turn back on the listeners and use the current system for which tabs
to use per server. That would certainly make it easier for people who
want to use Firebug occasionally, but don't need it all the time.

Assuming that is not possible/desirable for some reason, you raised
another point:

> Ok, I agree, but now to the details. If the user has
> Console enable
> Scripts disable
> Net enable for this site
> and the use selects "Turn all ON" what do you want the outcome to be?

I think it is partly just a labeling issue; take out the word "all".
IMO, the ideal behavior would be to turn back on the configured
choices. So if I'm in development mode and have Console and Net
enabled and Scripts disabled for my work server(s), and then I finish
developing and need to go back to just browsing normally (even on the
same work servers), I'd have a context menu option to "Turn Off
Firebug" that turns everything off. While Firebug is "off" it doesn't
work on any server. Later on, I need to test a new page, so I'd chose
"Turn On Firebug" and my configured settings for any servers I visit
would be restored.

Basically, your current system of configuring tabs on a server-by-
server basis could be left exactly as-is, with a higher level option
of "Turn everything off" or "Use the configured settings". In pseudo-
code, I'd expect it be a fairly simple construct, a basic if statement
like this:

if ( isFirebugDisabled == true ) {
' do nothing
} else {
' do everything it exactly the way it does now
}

Does that make any sense? I'm not familiar with the way Firefox
addons are coded, so I don't know how trivial it would be to
implement, but it seems like a simple approach that would be easy for
casual users while power users would just leave it always on and
configured the way they want it on a server-by-server basis.

Just a thought...
Jim

[John J Barton]

On Jul 30, 10:56 am, Jim Stoner <jim.sto...@esc.edu> wrote:
> developing and then off again afterward.  Turning it on isn't a
> problem, but turning them off again gets annoying, doing it tab-by-
> tab.  It's not a huge problem or anything, it's just annoying compared
> to the old approach of enabling/disabling Firebug globally.

I buy this argument, that the function we need it "Turn Off", not
"Disable for SIte"

>
> > I have been thinking about making the
> > check boxes all be selected by default, so the result would be very
> > close to previous Firebug (open then activiate).
>
> That would help, but it would also be nice to have a simple way to
> deactivate too.  Deactivating is much more annoying than activating
> currently.
>
> > If the user turns Firebug "on", what do we do about the current tabs?
> > Leave them, and hope the user realizes that only part of the function
> > of FIrebug is available? Reload them all so that the "On" state is
> > correctly reflected in the UI?  Reload the top page?
>
> Personally, I'd think "leave them" is the right choice.  As a user, if

We discussed this today and decided to remove the auto-reload.

> I turn on new functionality after a page has loaded, I don't expect it
> to magically apply to the old content.  I would expect to have to
> manually refresh it.  At most, you could pop up an alert box reminding
> them of that.  Auto-refreshing it has the major disadvantage of not
> knowing what frame to reload.  There are a lot of sites where auto-
> reloading the top page will actually navigate away from the displayed
> content because the URL for the top page isn't related to displayed
> content in embedded frames or framesets.  I'd say it would be best for
> the user to chose how/what to reload.
>
> This brings up a side question I had.  If I recall correctly, in older
> versions of Firebug, it was either all enabled or all disabled.  The
> new version is always "partially enabled" in that the HTML, CSS and
> DOM tabs are always active.  Isn't that causing a performance hit on
> every page?

As far as I know, there is zero performance impact if these tabs are
active but not being used.
...