Extremely Disappointed in New Activation Model - Old Method Better

[HIghway of Life]

I have just installed Firefox 3.5 along with the new Firebug beta and
I found myself extremely disappointed. The new activation model keeps
Firebug off until I activate the panel. This is very undesired.
Previously, you were able to activate panels on a per-site basis and
it would always be active for that site until you deactivated it for
the site. This enabled me to catch errors that I would not have
otherwise seen. Now with the new model, the only way to keep Firebug
active is to close (hide) Firebug, but this is very undesired as it
opens on every page load and has proven to drive up the annoyance
factor to intolerable levels.

Can you please go back to the old activation method which was on a per-
site basis and was always on for the sites you activated it for, even
if the panel was not 'open'? Or at the very very least, give us users
the option to choose this activation model in the Firebug preferences.

Thanks from a previously happy to now extremely disappointed Firebug
user.
- Highway of Life
Software Engineer.

[johnjbarton]

I guess this is a duplicate post, but anyway I think once you
understand the new scheme it won't seem so bad after all. The only
case that we don't do a good job on is site which generate unique
URLs. For information on the new activation see
http://www.softwareishard.com/blog/firebug/how-to-enable-and-disable-firebug-14/

jjb

[HIghway of Life]

Hi John, thanks for the reply.

I read through the blog post, but I'm no closer to finding a good
solution for working with the new model -- only that it will cause
slow-downs in my normal workflow (and from reading other topics, it's
obviously caused a lot of frustrations from others over the same
issue).

In the previous model, it was possible to enable Firebug only for the
domains I needed it enabled for, all other browsing of websites was
not affected. It remained closed while active on that domain so that
it could catch any firebug logging or errors that would occur. While
browsing the domains I am working on development for, if an error
crops up, I catch it, I don't have to remember to turn Firebug on for
my session, or enable it for all web pages, which takes a huge hit on
the performance. If I forget to enable Firebug, I could miss these
errors.

In the old model, clicking the (x) hide your panel, now it deactivates
the panel and you have to go through all the steps required to
reactivate your settings. It's not intuitive that (x) means disable
Firebug. And especially since that exact button did something
completely different in Firebug 1.3 that everybody got used to.

You don’t have to please everybody by appeasing the 'vast majority',
but it would seem to me that if you have a vast number of users, each
of whom have a different preference, that control over that preference
should be paramount.
1.4 has simply taken the control away from the users over how they
wish Firebug to be active and enabled. If it were not for the speed of
Firefox 3.5 and Firebug 1.4, I would switch back to Firefox 3.0 just
so I could have the old activation model back.

In the various topics on this discussion forum, there are 4 topics
full of disappointed users with the new activation model. Of the
responses in those topics including the feedback topic, 72% of the
users either hated or were disappointed with the new model. 12% liked
the new model, and 16% were indifferent.

I'm really hoping Firebug will go back to the old model, or have some
kind of combination between the two models because I understand why it
was changed, but I do not think it was a good change for a lot of
people. - I would really hate to have to install a plugin to get the
desired functionality that already existed in a previous version.

There may also be bugs here that are causing much of the annoyance as
well.
E.g.: when you enable firebug, your subsequent pageload (not refresh)
will usually load with Firebug disabled, and clicking on the Firebug
icon is required to activate Firebug again, at which time it will
remain active.
Shutting down Firebug, the subsequent page load will not only
reactivate Firebug, but open the Firebug window as well. Requiring you
to shut it down a second time.
The third thing is the (x) causing Firebug to shut down unexpectedly
for all the users who were used to the functionality of Firebug 1.3

Thanks again for your time and work on Firebug. :)

[powermonger]

@Highway of Life
I second that.

[johnjbarton]

On Jul 1, 2:32 am, HIghway of Life <highwayofl...@gmail.com> wrote:
> Hi John, thanks for the reply.
>
> I read through the blog post, but I'm no closer to finding a good
> solution for working with the new model -- only that it will cause
> slow-downs in my normal workflow (and from reading other topics, it's
> obviously caused a lot of frustrations from others over the same
> issue).
>
> In the previous model, it was possible to enable Firebug only for the
> domains I needed it enabled for, all other browsing of websites was
> not affected. It remained closed while active on that domain so that
> it could catch any firebug logging or errors that would occur. While
> browsing the domains I am working on development for, if an error
> crops up, I catch it, I don't have to remember to turn Firebug on for
> my session, or enable it for all web pages, which takes a huge hit on
> the performance. If I forget to enable Firebug, I could miss these
> errors.

Still true in Firebug 1.4. The only difference is the UI. In 1.3 you
have to open the permissions panel and add domains manually. In 1.4,
you just open Firebug on the site the first time you need it.

>
> In the old model, clicking the (x) hide your panel, now it deactivates
> the panel and you have to go through all the steps required to
> reactivate your settings. It's not intuitive that (x) means disable
> Firebug. And especially since that exact button did something
> completely different in Firebug 1.3 that everybody got used to.

Clicking the [X] closes Firebug. That is pretty standard user
interface. For example it is used in every application on Windows,
Linux, and Mac. (Well of course Mac uses a circle rather than a
square, as they would).

>
> You don’t have to please everybody by appeasing the 'vast majority',
> but it would seem to me that if you have a vast number of users, each
> of whom have a different preference, that control over that preference
> should be paramount.

Which "vast" are you talking about? The dozen or so folks who have
posted here about 1.4? Or the dozen or so folks who complained about
1.3? Really we can't use newsgroup posts as a proxy for votes. What we
can to is try to make the tool work very well. The key to that is
concrete, specific, detailed descriptions rather than "make it work
like it used to".

> 1.4 has simply taken the control away from the users over how they
> wish Firebug to be active and enabled. If it were not for the speed of
> Firefox 3.5 and Firebug 1.4, I would switch back to Firefox 3.0 just
> so I could have the old activation model back.

>
> In the various topics on this discussion forum, there are 4 topics
> full of disappointed users with the new activation model. Of the
> responses in those topics including the feedback topic, 72% of the
> users either hated or were disappointed with the new model. 12% liked
> the new model, and 16% were indifferent.

Yes, but you are taking 72% of a tiny fraction of all Firebug users.
We had about 8,000 beta users, so even if 40 people here did not like
it, 40/8000 is only 0.5%, so we have 99.5% satisfied users. Do you
buy that? Me neither, so let's give up trying to count people who
complain.

>
> I'm really hoping Firebug will go back to the old model, or have some
> kind of combination between the two models because I understand why it
> was changed, but I do not think it was a good change for a lot of
> people. - I would really hate to have to install a plugin to get the
> desired functionality that already existed in a previous version.

It is possible that someone will come along to work on Firebug and
want to work on the activation. Possible but unlikely.

>
> There may also be bugs here that are causing much of the annoyance as
> well.
> E.g.: when you enable firebug, your subsequent pageload (not refresh)
> will usually load with Firebug disabled, and clicking on the Firebug
> icon is required to activate Firebug again, at which time it will
> remain active.

? I don't understand what you are saying. What is "pageload"?

> Shutting down Firebug, the subsequent page load will not only
> reactivate Firebug, but open the Firebug window as well. Requiring you
> to shut it down a second time.

? What will work much better is to describe the actions in terms of
the user interface, a single step at a time, eg:
1) Click the red [X] box in the upper right, Firebug UI disappears.
2) ...

> The third thing is the (x) causing Firebug to shut down unexpectedly
> for all the users who were used to the functionality of Firebug 1.3

[x] closes Firebug as I explained. What else would it do?

>
> Thanks again for your time and work on Firebug. :)

You're welcome!

[HIghway of Life]

Hi John,

Thanks for the reply.

I'm not sure how much more clear I could have been, but I since words
are not enough, and a picture is worth a thousand words, I'll create a
quick screencast that should be worth quite a few words. :)
Hopefully this helps identify many of the problems with the activation
model we have been having.

Thanks!!
http://highwayoflife.net/jing/Firebug_Activation_Issues.swf

[Luke Maurer]

On Jul 1, 7:24 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> Still true in Firebug 1.4. The only difference is the UI. In 1.3 you
> have to open the permissions panel and add domains manually. In 1.4,
> you just open Firebug on the site the first time you need it.

Does that work for the whole domain? Will it work for manually-entered
URLs (rather than followed links)? And what happens when I close the
console - does it forget that I wanted it activated for the domain?

> Clicking the [X] closes Firebug. That is pretty standard user
> interface. For example it is used in every application on Windows,
> Linux, and Mac.

Wrong. Clicking the [X] closes *the window*. I have a buddy list open.
If I click the [X], it closes *the buddy list,* not the IM client.
(I'm using Pidgin, but AFAIK *all* clients work like this.) In fact,
*just like Firebug,* it leaves a little icon in the bottom-right.
Closing the buddy list does *nothing* but close the buddy list. The
Firebug console is just like the buddy list - it's important for
interacting with the app, but the app still chugs along when I'm not
interacting with it.

(As an aside, almost NO apps on the Mac work as you describe; even if
you close all the windows, *the app is still running.* Granted, it's a
Mac oddity, but clearly the connection between closing a window and
quitting an app is far weaker than you're implying.)

This design quirk strongly compounds the problem with having
activation remembered the way it is, since if you close the console to
get it out of the way, not only have you inadvertently deactivated the
Ajax listener for the page, *but you've disabled Firebug for the page
permanently.* Closing the console is simply not the significant user
decision you've made it out to be - if I close the console, all I want
to do is close the console. I don't want to disable Firebug, and I
*certainly* don't mean to tell Firebug not to activate automatically
for the site anymore.

> Which "vast" are you talking about? The dozen or so folks who have
> posted here about 1.4? Or the dozen or so folks who complained about
> 1.3? Really we can't use newsgroup posts as a proxy for votes. What we
> can to is try to make the tool work very well. The key to that is
> concrete, specific, detailed descriptions rather than "make it work
> like it used to".

People have described here at length what their workflow was and how
it's been hamstrung by 1.4, and how 1.4's behavior is confusing and
unhelpful. Also, the reason few people have piped up before now is
that few people have needed to upgrade to 1.4. Now that FF3.5 is out,
the group has been deluged.

> Yes, but you are taking 72% of a tiny fraction of all Firebug users.
> We had about 8,000 beta users, so even if 40 people here did not like
> it, 40/8000 is only 0.5%, so we have 99.5% satisfied users.  Do you
> buy that? Me neither, so let's give up trying to count people who
> complain.

You're assuming that 100% of the people who didn't like it complained.

> It is possible that someone will come along to work on Firebug and
> want to work on the activation. Possible but unlikely.

Uh, given the number of dissatisfied users around here, and how most
Firebug users, particularly the most fervent, are themselves
JavaScript devs, it's not only likely, it's a near-certainty.

- Luke

[Kara Rawson]

thatsa great idea.!!!

kara

[johnjbarton]

On Jul 1, 1:17 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> On Jul 1, 7:24 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
>
> > Still true in Firebug 1.4. The only difference is the UI. In 1.3 you
> > have to open the permissions panel and add domains manually. In 1.4,
> > you just open Firebug on the site the first time you need it.
>
> Does that work for the whole domain?

It will work for pages you open from the opened page.

Will it work for manually-entered
> URLs (rather than followed links)?

No.

And what happens when I close the
> console - does it forget that I wanted it activated for the domain?

I'm not sure what you mean by "console".

>
> > Clicking the [X] closes Firebug. That is pretty standard user
> > interface. For example it is used in every application on Windows,
> > Linux, and Mac.
>
> Wrong. Clicking the [X] closes *the window*. I have a buddy list open.
> If I click the [X], it closes *the buddy list,* not the IM client.
> (I'm using Pidgin, but AFAIK *all* clients work like this.) In fact,
> *just like Firebug,* it leaves a little icon in the bottom-right.
> Closing the buddy list does *nothing* but close the buddy list. The
> Firebug console is just like the buddy list - it's important for
> interacting with the app, but the app still chugs along when I'm not
> interacting with it.

Oh then "commonly used in many apps". Or "used in some apps".

>
> (As an aside, almost NO apps on the Mac work as you describe; even if
> you close all the windows, *the app is still running.* Granted, it's a
> Mac oddity, but clearly the connection between closing a window and
> quitting an app is far weaker than you're implying.)

Ok, fine. Anyway, the [X] in Firebug closes the UI and deactivates the
page.

>
> This design quirk strongly compounds the problem with having
> activation remembered the way it is, since if you close the console to
> get it out of the way, not only have you inadvertently deactivated the
> Ajax listener for the page, *but you've disabled Firebug for the page
> permanently.* Closing the console is simply not the significant user
> decision you've made it out to be - if I close the console, all I want
> to do is close the console. I don't want to disable Firebug, and I
> *certainly* don't mean to tell Firebug not to activate automatically
> for the site anymore.

If you want Firebug to remain active but pull down the UI, use the
minimize icon [_].

>
> > Which "vast" are you talking about? The dozen or so folks who have
> > posted here about 1.4? Or the dozen or so folks who complained about
> > 1.3? Really we can't use newsgroup posts as a proxy for votes. What we
> > can to is try to make the tool work very well. The key to that is
> > concrete, specific, detailed descriptions rather than "make it work
> > like it used to".
>
> People have described here at length what their workflow was and how
> it's been hamstrung by 1.4, and how 1.4's behavior is confusing and
> unhelpful. Also, the reason few people have piped up before now is
> that few people have needed to upgrade to 1.4. Now that FF3.5 is out,
> the group has been deluged.

More detailed description of the problems would be more effective for
us. I'm sorry that folks waited until now to complain, but really
that's not something we have any control over.

>
> > Yes, but you are taking 72% of a tiny fraction of all Firebug users.
> > We had about 8,000 beta users, so even if 40 people here did not like
> > it, 40/8000 is only 0.5%, so we have 99.5% satisfied users.  Do you
> > buy that? Me neither, so let's give up trying to count people who
> > complain.
>
> You're assuming that 100% of the people who didn't like it complained.

You bet. Any assumption is as good as any other one. Which is why one
can't use it as a proxy for voting.

>
> > It is possible that someone will come along to work on Firebug and
> > want to work on the activation. Possible but unlikely.
>
> Uh, given the number of dissatisfied users around here, and how most
> Firebug users, particularly the most fervent, are themselves
> JavaScript devs, it's not only likely, it's a near-certainty.

That would be fantastic! Really. There are so many cool things that
can be done with Firebug and it has such a huge impact on the worlds
most important communications medium, I really encourage anyone who is
interested. Do not hesitate and we want to help you.

jjb

[johnjbarton]

Its hard to tell for sure from the video but it looks like the URLs
have unique ids. That is one weakness have identified. I think we
have a solution in 1.5a7.
jjb

On Jul 1, 12:59 pm, HIghway of Life <highwayofl...@gmail.com> wrote:
> Hi John,
>
> Thanks for the reply.
>
> I'm not sure how much more clear I could have been, but I since words
> are not enough, and a picture is worth a thousand words, I'll create a
> quick screencast that should be worth quite a few words. :)
> Hopefully this helps identify many of the problems with the activation
> model we have been having.
>

> Thanks!!http://highwayoflife.net/jing/Firebug_Activation_Issues.swf

[HIghway of Life]

On Jul 1, 1:17 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:

> This design quirk strongly compounds the problem with having
> activation remembered the way it is, since if you close the console to
> get it out of the way, not only have you inadvertently deactivated the
> Ajax listener for the page, *but you've disabled Firebug for the page
> permanently.* Closing the console is simply not the significant user
> decision you've made it out to be - if I close the console, all I want
> to do is close the console. I don't want to disable Firebug, and I
> *certainly* don't mean to tell Firebug not to activate automatically
> for the site anymore.

Echoing my agreement, my issues with it were the same. Although
admittedly, I will learn to work with it, but it was annoying for a
while because (x) does not mean “close down, turn off and disable” on
any other application on the Mac. It must means: close the window. The
application is always left open unless I specifically choose to
disable or exit it. Which is what I liked about Firebug 1.3, in that
it was disabled only when you told it to be.

On Jul 1, 1:17 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:

> People have described here at length what their workflow was and how
> it's been hamstrung by 1.4, and how 1.4's behavior is confusing and
> unhelpful. Also, the reason few people have piped up before now is
> that few people have needed to upgrade to 1.4. Now that FF3.5 is out,
> the group has been deluged.

Indeed I heard there was a new activation model from a friend and it
was less than desired, so I simply avoided updating to a Firefox 3.5
beta until it was released, then it became apparent that I needed to
say something so that the workflow would not continue to be
frustrating on a daily basis. :)

[HIghway of Life]

On Jul 1, 1:36 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> Its hard to tell for sure from the video but it looks like the URLs
> have unique ids.  That is one weakness have identified. I think we
> have a solution in 1.5a7.
> jjb

Hi John, I installed 1.5a7 and can confirm that this has been
fixed. :)

Thanks!

[sir_brizz]

Sorry, but what does 8,000 beta users have to do with anything (and
how is such a number tracked, anyway? I've downloaded Firebug alphas/
betas from at least 5 unique locations and I'm sure many others have
done the same)? The people posting here are the people that care about
Firebug development, and the ratio represented should, roughly,
correlate back to that entire 8,000. If not, then what use is any
statistical analysis in the world today? They wouldn't do it if the
methods weren't mostly proven. Frankly, if satisfaction rate is
anywhere near 50%, I would see changing the activation model as an
utter failure and complete waste of time (I'm sorry to say).

The current functionality is overcomplicated and inconvenient. Here's
how I explained it to a friend (and this is all true based on my
testing of 1.4b3):

you click the bug, it turns on for the current tab
you refresh, and all the panels work for the current page
oh, but first you have to right click the bug and say "enable all
panels"
if you click the bug then firebug will stay open on that tab
if you want to hide the panel, you have to click minimize not the x
[confusing]
if you mistakenly click the x, you have to then click the bug, refresh
the page, then minimize
if it's minimized and you go to another page, it disables
if you go back to a page it was enabled on, it re-enables
but of course if you hit the x on accident, it forgets that setting

Okay, now let's compare that to 1.3:

Click bug
check three boxes
click a button

So, how can we continue to claim this is not more complex? It
absolutely is!

On Jul 1, 2:32 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > > Yes, but you are taking 72% of a tiny fraction of all Firebug users.
> > > We had about 8,000 beta users, so even if 40 people here did not like
> > > it, 40/8000 is only 0.5%, so we have 99.5% satisfied users.  Do you
> > > buy that? Me neither, so let's give up trying to count people who
> > > complain.
>
> > You're assuming that 100% of the people who didn't like it complained.
>
> You bet. Any assumption is as good as any other one. Which is why one
> can't use it as a proxy for voting.

> jjb

[johnjbarton]

On Jul 1, 2:41 pm, sir_brizz <bj.car...@gmail.com> wrote:
> Sorry, but what does 8,000 beta users have to do with anything (and
> how is such a number tracked, anyway? I've downloaded Firebug alphas/
> betas from at least 5 unique locations and I'm sure many others have
> done the same)? The people posting here are the people that care about
> Firebug development, and the ratio represented should, roughly,
> correlate back to that entire 8,000. If not, then what use is any
> statistical analysis in the world today? They wouldn't do it if the
> methods weren't mostly proven. Frankly, if satisfaction rate is
> anywhere near 50%, I would see changing the activation model as an
> utter failure and complete waste of time (I'm sorry to say).

The only people I listen to are people to speak up. So the numbers
just do not matter, for or against any feature. The only part I am
interested in how can we make Firebug better. I'm not going to
develop or design by any voting scheme.

>
> The current functionality is overcomplicated and inconvenient. Here's
> how I explained it to a friend (and this is all true based on my
> testing of 1.4b3):
>
> you click the bug, it turns on for the current tab
> you refresh, and all the panels work for the current page
> oh, but first you have to right click the bug and say "enable all
> panels"

Once only.

> if you click the bug then firebug will stay open on that tab
> if you want to hide the panel, you have to click minimize not the x
> [confusing]

I'm confident you will learn this small difference quickly.

> if you mistakenly click the x, you have to then click the bug, refresh
> the page, then minimize
> if it's minimized and you go to another page, it disables

The activate/deactivate is not related to minimize.

> if you go back to a page it was enabled on, it re-enables

We would say: if you go back to a page that was active, FIrebug will
open.

> but of course if you hit the x on accident, it forgets that setting

But I am sure you will get this after a few trials.

>
> Okay, now let's compare that to 1.3:
>
> Click bug
> check three boxes
> click a button

But once you get the hang of 1.4, you have:
Click the bug
that is it.

>
> So, how can we continue to claim this is not more complex? It
> absolutely is!

Because 1 < 5. Give it a chance.

jjb

[sir_brizz]

On Jul 1, 3:55 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 1, 2:41 pm, sir_brizz <bj.car...@gmail.com> wrote:
>
> > Sorry, but what does 8,000 beta users have to do with anything (and
> > how is such a number tracked, anyway? I've downloaded Firebug alphas/
> > betas from at least 5 unique locations and I'm sure many others have
> > done the same)? The people posting here are the people that care about
> > Firebug development, and the ratio represented should, roughly,
> > correlate back to that entire 8,000. If not, then what use is any
> > statistical analysis in the world today? They wouldn't do it if the
> > methods weren't mostly proven. Frankly, if satisfaction rate is
> > anywhere near 50%, I would see changing the activation model as an
> > utter failure and complete waste of time (I'm sorry to say).
>
> The only people I listen to are people to speak up. So the numbers
> just do not matter, for or against any feature. The only part I am
> interested in how can we make Firebug better.  I'm not going to
> develop or design by any voting scheme.
>

And I don't think you should. The outcry by the people who ARE
speaking up does speak for itself, in my opinion.

>
>
> > The current functionality is overcomplicated and inconvenient. Here's
> > how I explained it to a friend (and this is all true based on my
> > testing of 1.4b3):
>
> > you click the bug, it turns on for the current tab
> > you refresh, and all the panels work for the current page
> > oh, but first you have to right click the bug and say "enable all
> > panels"
>
> Once only.
>
> > if you click the bug then firebug will stay open on that tab
> > if you want to hide the panel, you have to click minimize not the x
> > [confusing]
>
> I'm confident you will learn this small difference quickly.
>
> > if you mistakenly click the x, you have to then click the bug, refresh
> > the page, then minimize
> > if it's minimized and you go to another page, it disables
>
> The activate/deactivate is not related to minimize.
>
> > if you go back to a page it was enabled on, it re-enables
>
> We would say: if you go back to a page that was active, FIrebug will
> open.
>
> > but of course if you hit the x on accident, it forgets that setting
>
> But I am sure you will get this after a few trials.

Okay, but that's all inconsequential. If I mistakenly click the x
(which is bound to happen based on its position), then the model
crumbles and becomes an annoying pain to the user. The 1.3 model
doesn't have this problem.

>
>
>
> > Okay, now let's compare that to 1.3:
>
> > Click bug
> > check three boxes
> > click a button
>
> But once you get the hang of 1.4, you have:
> Click the bug
> that is it.

That's not exactly correct. First, I'm obviously talking about initial
page load setup here. If we compare end results, in both models
firebug should work after being enabled on a page by clicking the bug,
one step. Second, in 1.4 depending on the state of the current page,
it would be:
Click the bug
Refresh the page

Still, the margin of error in 1.4 is significantly higher when all is
said and done due to the functionality of "closing" the panel (as
opposed to minimizing it). In 1.3 this is of no concern, since, once
you enable Firebug for a domain, you have to very specifically disable
it for that domain in order for it to stop functioning. In 1.4 I only
have to unintentionally click the x button and complete deactivation
takes place.

I've been using 1.4 off and on for the last several months, and I've
not gained any ounce of respect for this activation model. I think
it's rather telling that all along its development the question was
asked "how should [some process] function?", a question which simply
did not apply to the old model at all. For example, if I enable
Firebug on a tab and minimize it then browse to another page, it is
disabled on the following page. Presumably, it only enabled for the
first page and not for the current tab, yet if I have the panel up it
stays active for the tab on every page. How should this function? In
1.3 there was no question. If the panel wasn't enabled for the
following page's domain, you would just enable it and refresh and you
were done taking action. In the new model, you have to wonder about
what Firebug should be doing in this scenario, which immediately makes
the model more complicated than it should be. I would think that the
tab rule should apply here, since Firebug was enabled inside the tab.
But, of course, that's not how it works.

>
>
>
> > So, how can we continue to claim this is not more complex? It
> > absolutely is!
>
> Because 1 < 5.   Give it a chance.

But, really, you're saying that 1 or 2 is less than 1. (And that is
not considering the number of steps on ensuing pages in a domain,
although this appears to have been fixed in the latest alpha of 1.5)

>
> jjb

[Kara Rawson]

@ sir b
i agree at this point..... +1

OMG im sick of reading all of this, just change it to a white and black
list, if its on its on, keep it on till you shut it off by clicking the
button, K.I.S.S.

kara

[johnjbarton]

On Jul 1, 3:38 pm, sir_brizz <bj.car...@gmail.com> wrote:
...,

> one step. Second, in 1.4 depending on the state of the current page,
> it would be:
> Click the bug
> Refresh the page

The page reload is only needed if you have never activated the page
before.

>
> Still, the margin of error in 1.4 is significantly higher when all is
> said and done due to the functionality of "closing" the panel (as
> opposed to minimizing it). In 1.3 this is of no concern, since, once
> you enable Firebug for a domain, you have to very specifically disable
> it for that domain in order for it to stop functioning. In 1.4 I only

Hmm, so now you are saying that because its hard to deactivate Firebug
in 1.3 its a good thing?

> have to unintentionally click the x button and complete deactivation
> takes place.

We added a minimize button. I'm sorry you'll just have to learn to use
it. It just a few pixels to the left.

>
> I've been using 1.4 off and on for the last several months, and I've
> not gained any ounce of respect for this activation model. I think
> it's rather telling that all along its development the question was
> asked "how should [some process] function?", a question which simply
> did not apply to the old model at all. For example, if I enable

In this regard I can speak from experience in the development of 1.3.
There more questions and quite a lot complains.

> Firebug on a tab and minimize it then browse to another page, it is
> disabled on the following page. Presumably, it only enabled for the
> first page and not for the current tab, yet if I have the panel up it
> stays active for the tab on every page. How should this function? In
> 1.3 there was no question. If the panel wasn't enabled for the
> following page's domain, you would just enable it and refresh and you
> were done taking action. In the new model, you have to wonder about
> what Firebug should be doing in this scenario, which immediately makes
> the model more complicated than it should be. I would think that the
> tab rule should apply here, since Firebug was enabled inside the tab.
> But, of course, that's not how it works.

I'm sorry but I can't sort out what you are saying here. I suggest
that if you can give the individual steps by the buttons then your
reaction or issue it will be easier to understand.

>
>
>
> > > So, how can we continue to claim this is not more complex? It
> > > absolutely is!
>
> > Because 1 < 5.   Give it a chance.
>
> But, really, you're saying that 1 or 2 is less than 1. (And that is
> not considering the number of steps on ensuing pages in a domain,
> although this appears to have been fixed in the latest alpha of 1.5)

Yes, based on discussions in this group including ones you contributed
to I realized there was a simple and coherent way to support same-
domain activation. Try it and let us know.

jjb

[sir_brizz]

On Jul 1, 6:17 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 1, 3:38 pm, sir_brizz <bj.car...@gmail.com> wrote:
> > I've been using 1.4 off and on for the last several months, and I've
> > not gained any ounce of respect for this activation model. I think
> > it's rather telling that all along its development the question was
> > asked "how should [some process] function?", a question which simply
> > did not apply to the old model at all. For example, if I enable
>
> In this regard I can speak from experience in the development of 1.3.
> There more questions and quite a lot complains.

Well, I was only around for the alphas/betas of 1.3, but I don't
recall a lot of issues surrounding the activation model as just
general insecurity about moving on to it.

>
> > Firebug on a tab and minimize it then browse to another page, it is
> > disabled on the following page. Presumably, it only enabled for the
> > first page and not for the current tab, yet if I have the panel up it
> > stays active for the tab on every page. How should this function? In
> > 1.3 there was no question. If the panel wasn't enabled for the
> > following page's domain, you would just enable it and refresh and you
> > were done taking action. In the new model, you have to wonder about
> > what Firebug should be doing in this scenario, which immediately makes
> > the model more complicated than it should be. I would think that the
> > tab rule should apply here, since Firebug was enabled inside the tab.
> > But, of course, that's not how it works.
>
> I'm sorry but I can't sort out what you are saying here. I suggest
> that if you can give the individual steps by the buttons then your
> reaction or issue it will be easier to understand.
>

Sure, it's easy to replicate and is probably by design.

Open any page
Click to enable Firebug
Click minimize (the bug will still be lit)
Browse to another page (bug is not lit)

That's really all. I would think that the per-tab activation would
take effect in this case, but it doesn't. That by itself would resolve
a lot of my complaints with this activation model. However, this gets
into other questions that are also questions with the per-tab
activation. Should Firebug save activated settings for each domain you
visit while it is activated? I don't know.

>
>
> > > > So, how can we continue to claim this is not more complex? It
> > > > absolutely is!
>
> > > Because 1 < 5.   Give it a chance.
>
> > But, really, you're saying that 1 or 2 is less than 1. (And that is
> > not considering the number of steps on ensuing pages in a domain,
> > although this appears to have been fixed in the latest alpha of 1.5)
>
> Yes, based on discussions in this group including ones you contributed
> to I realized there was a simple and coherent way to support same-
> domain activation. Try it and let us know.

I'll give it a shot. This might solve a lot of my complaints, as
currently it seems page based (which is entirely annoying since 1.3
was domain based).

>
> jjb

[johnjbarton]

On Jul 1, 5:30 pm, sir_brizz <bj.car...@gmail.com> wrote:
> On Jul 1, 6:17 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
>
> > On Jul 1, 3:38 pm, sir_brizz <bj.car...@gmail.com> wrote:
> > > I've been using 1.4 off and on for the last several months, and I've
> > > not gained any ounce of respect for this activation model. I think
> > > it's rather telling that all along its development the question was
> > > asked "how should [some process] function?", a question which simply
> > > did not apply to the old model at all. For example, if I enable
>
> > In this regard I can speak from experience in the development of 1.3.
> > There more questions and quite a lot complains.
>
> Well, I was only around for the alphas/betas of 1.3, but I don't
> recall a lot of issues surrounding the activation model as just
> general insecurity about moving on to it.

Maybe being on the receiving end of the complaints makes the more
memorable.

> > > Firebug on a tab and minimize it then browse to another page, it is
> > > disabled on the following page. Presumably, it only enabled for the
> > > first page and not for the current tab, yet if I have the panel up it
> > > stays active for the tab on every page. How should this function? In
> > > 1.3 there was no question. If the panel wasn't enabled for the
> > > following page's domain, you would just enable it and refresh and you
> > > were done taking action. In the new model, you have to wonder about
> > > what Firebug should be doing in this scenario, which immediately makes
> > > the model more complicated than it should be. I would think that the
> > > tab rule should apply here, since Firebug was enabled inside the tab.
> > > But, of course, that's not how it works.
>
> > I'm sorry but I can't sort out what you are saying here. I suggest
> > that if you can give the individual steps by the buttons then your
> > reaction or issue it will be easier to understand.
>
> Sure, it's easy to replicate and is probably by design.
>
> Open any page
> Click to enable Firebug
> Click minimize (the bug will still be lit)
> Browse to another page (bug is not lit)

Because the new page is not activated. Concretely, you the user never
press "open firebug" on that URL.

>
> That's really all. I would think that the per-tab activation would
> take effect in this case, but it doesn't. That by itself would resolve

Oh. That explains a lot: it's not per-tab activation. Its not related
to tabs. It's per URL.

> a lot of my complaints with this activation model. However, this gets
> into other questions that are also questions with the per-tab
> activation. Should Firebug save activated settings for each domain you
> visit while it is activated? I don't know.

Firebug saves the activation per URL. Nothing about tabs.

The Activate Same Domain just chops down the URLs and uses that for
activation.
..

jjb

[sir_brizz]

Hmm, I see. I thought that if you opened Firebug in a tab that it
would stay active for that tab no matter where you go. This isn't
actually the case. It is still a good "what should happen in this
situation?" scenario, though. I would think it should stay open for
your browsing session if you had it open. As it stands, it just closes
and deactivates if you browse to another page.

[johnjbarton]

On Jul 1, 6:50 pm, sir_brizz <bj.car...@gmail.com> wrote:
> Hmm, I see. I thought that if you opened Firebug in a tab that it
> would stay active for that tab no matter where you go. This isn't
> actually the case. It is still a good "what should happen in this
> situation?" scenario, though. I would think it should stay open for
> your browsing session if you had it open. As it stands, it just closes
> and deactivates if you browse to another page.

Yes, because most users who need the console and script panel are
working on specific sites. They open Firebug for those sites. If they
browse to another site we assume they taking a break, so we don't
activate for that new URL.

jjb

[sir_brizz]

I can understand that, I suppose... but then, why wouldn't they just
open a new tab if that were the case?

[Highway of Life]

On Jul 1, 8:36 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> Yes, because most users who need the console and script panel are
> working on specific sites. They open Firebug for those sites. If they
> browse to another site we assume they taking a break, so we don't
> activate for that new URL.
>
> jjb

Now when you say "URL", do you mean "domain" or "unique page URL" ? -
it sounds like "unique page", but in the new alpha, it seems to act on
a per-domain basis. Which is good.
This is important because, for example if I am developing on a site, I
want Firebug to be either on or off for the entire domain, not for one
specific page.

So far the new alpha seems to have solved most of my complaints
(except for the [x] deactivation/close button, which while I am
getting used to it, it's not getting any less annoying).

Thanks!

[johnjbarton]

On Jul 2, 12:24 pm, Highway of Life <highwayofl...@gmail.com> wrote:
> On Jul 1, 8:36 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
>
> > Yes, because most users who need the console and script panel are
> > working on specific sites. They open Firebug for those sites. If they
> > browse to another site we assume they taking a break, so we don't
> > activate for that new URL.
>
> > jjb
>
> Now when you say "URL", do you mean "domain" or "unique page URL" ? -

If Firebug > Firebug Menu > Options > Activate Same Origin URLs is
checked, then the test is on the second level domain, eg http://ibm.com
for http://almaden.ibm.com.
Else the test is on the page URL.


Activate Same Origin URL is on by default.
jjb

[Wouter van Campen]

I recently upgraded to the new firefox aswell, and thus was also
forced to upgrade my firebug.

I had the same frustrations as Highway of Life (and a few other people
as we can read in other topics). In despiration, i installed the 1.5
beta version (currently version: 1.5X.0a08). Now that i'm getting used
to the new activation model, my frustrations have gone away (except
when i forget i have to minimize instead of clicking the [X] button
but that is my own fault). What i now do is hit the "Off for all web
pages" option. Then, when i'm at my url or domain i need firebug, i
just click the small icon in the bottom-left corner and firebug
springs to life. So far, from that point on firebug is disabled on
every page/url/website/domain except the ones i clicked it open on.

In previous versions of firebug, I used it the other way around. It
was always active unless i told it not to be for a certain website.
Now that i'm getting used to it, I think the new model is actually
better. Firebug slows down my firefox so having it enabled only on the
pages where i need it, and disabled on all the others is a good thing.
Where in the old model, it always was somewhat of a struggle to get
firebug to be disabled on a website.

The only thing i would really like is a list where all the sites/
domains are listed on wich firebug is enabled by default. Other than
that, just get used to it and it'll be just like using < 1.3

Wouter

[Brian Di Palma]

On Fri, Jul 3, 2009 at 11:32 AM, Wouter van Campen <wvca...@gmail.com> wrote:

The only thing i would really like is a list where all the sites/
domains are listed on wich firebug is enabled by default. Other than
that, just get used to it and it'll be just like using < 1.3

That's what a lot of us would like back too.

I use Firebug to work so I don't care about it slowing down my browsing experience since I very rarely use the browser for non development at work.

It's hugely annoying that Firebug no longer seems to log anything when it is not displayed.

I really *really* don't care about the overhead I just want a tool that allows me to debug problems like 1.3 did.

Wouter

[johnjbarton]

On Jul 4, 8:01 am, Brian Di Palma <off...@gmail.com> wrote:

> On Fri, Jul 3, 2009 at 11:32 AM, Wouter van Campen <wvcam...@gmail.com>wrote:
>
>
>
> > The only thing i would really like is a list where all the sites/
> > domains are listed on wich firebug is enabled by default. Other than
> > that, just get used to it and it'll be just like using < 1.3
>
> That's what a lot of us would like back too.

(I'm really sensitive to the numbers game now: truly how many is "a
lot"? In fact we don't have any way to know how many people have any
particular opinion aboug Firebug features. That being the case, we
have no other choice than to listen to people who describe their
problems in clear, concrete terms so we can understand them).

To help me understand what is requested: a list of the domains that
Firebug would be active on if you loaded their URL?

>
> I use Firebug to work so I don't care about it slowing down my browsing
> experience since I very rarely use the browser for non development at work.
>
> It's hugely annoying that Firebug no longer seems to log anything when it is
> not displayed.

? If you can explain what you mean in terms of the Firebug user
interface controls maybe there is something that can be done. You may
think what you said is clear, but it makes no sense to me because I
get logging:
From the OS console when I have extensions.firebug-tracing-
service.DBG_toOSConsole true (not recommended for users)
From the Firebug tracing console when I have it open and an tracing
option selected.
In the console panel when I have it enabled.
All of this can happen and Firebug need not be showing its user
interface.

> I really *really* don't care about the overhead I just want a tool that
> allows me to debug problems like 1.3 did.

Unfortunately --> lots <-- of people do not agree with that point of
view ;-)

jjb

[Brian Di Palma]

On Sat, Jul 4, 2009 at 4:29 PM, johnjbarton <johnj...@johnjbarton.com> wrote:

On Jul 4, 8:01 am, Brian Di Palma <off...@gmail.com> wrote:
> On Fri, Jul 3, 2009 at 11:32 AM, Wouter van Campen <wvcam...@gmail.com>wrote:

>
>
>
> > The only thing i would really like is a list where all the sites/
> > domains are listed on wich firebug is enabled by default. Other than
> > that, just get used to it and it'll be just like using < 1.3
>
> That's what a lot of us would like back too.

(I'm really sensitive to the numbers game now: truly how many is "a
lot"? In fact we don't have any way to know how many people have any
particular opinion aboug Firebug features. That being the case, we
have no other choice than to listen to people who describe their
problems in clear, concrete terms so we can understand them).

To help me understand what is requested: a list of the domains that
Firebug would be active on if you loaded their URL?>

Please John, it's quite obvious that the new activation model has generated by
*far* the most number of emails of any issue in the Firebug groups.

I see no one coming out in support of it - personally I don't expect to ever see
it changed so I'm just trying to live with it.

My main problem is that even when I set Firebug to be on for all pages and
I start it up and enable it for my dev application the next time I restart Firefox Firebug
is yet again disabled. Why?! I don't click the 'X' at most I minimize Firebug.
Now of course I can press the Firebug icon and it comes to life so you could
say that it's not a huge issue but the problem is that sometimes I must debug issues
with pages that literally fly past (Unit tests for example) and it's dealing with those cases
that I foresee a lot of problems eventually.

Even small things like debuggers not being triggered because Firebug is not on, or
errors not logging and showing up as errors on the status bar (can be very useful!).
I am confused by this behavior and I am not convinced that it is intended so I will
try with a new profile and installation and see if it fixes it. If it is intended I am very
disappointed and frustrated.  

Debugging has an overhead but I am willing to pay it if others are not willing to pay
then tough luck to them I say. You're breaking the back of the application developer
so that a web page developer suffers a smaller impact from running Firebug!

I don't understand the logic of that if you want web page tools use Web Developer Toolbar.
Firebug is for *debugging* I don't worry about Visual Studio triggering when I use IE
and once it was the same with Firebug - not any longer unfortunately.
 
 

[johnjbarton]

On Jul 6, 3:32 pm, Brian Di Palma <off...@gmail.com> wrote:

Brian, do you use Firebug in the detached external window?

If yes please wait for Firebug 1.5a9 and give me feedback on that
version.

If no, please pick the issue that most causes you a problem and
describe it in a step wise fashion so I can understand it.

jjb

[johnjbarton]

On Jul 6, 3:53 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 6, 3:32 pm, Brian Di Palma <off...@gmail.com> wrote:
>
> Brian, do you use Firebug in the detached external window?
>
> If yes please wait for Firebug 1.5a9 and give me feedback on that
> version.

getfirebug.com/releases has 1.5.0a9. Let me know if this addresses
your issues.
jjb