The discussions on this newsgroup helped me realize that another way
of explaining the user interface in 1.4 may help people familiar with
the 1.3 mechanism.

In 1.4 you add a domain to the whitelist by opening Firebug on a page
in that domain. So for example if you open the URL http://getfirebug.com,
then open Firebug, the domain getfirebug.com is added to the
whitelist. If you subsequently open http://blog.getfirebug.com,
Firebug will be opened because getfirebug.com is on the whitelist.

In 1.4 you add a domain to the blacklist by clicking [X] in the upper
right corner of Firebug when Firebug is open on a page in that domain.
Continuing the example above, while on http://blog.getfirebug.com, if
you click the [X] button Firebug closes. When you go back to
http://getfirebug.com, Firebug is still closed because getfirebug.com
is on the blacklist.

A few details:

First the mechanism used for the tests is closer to the same-origin
policy of Firefox than simple domain comparison. The case that will
probably confuse people is http vs https: Firebug like Firefox
considers http://getfirebug.com to be different than https://getfirebug.com.

Second, this description assumes you have 1.4b5 or later and that you
leave the default option Activate Same Origin checked.

Third, under the covers the white list is implemented with Firefox
page annotation database. The annotation name is "firebug/history",
whitelist pages are marked "firebugged.showFirebug" and blacklist
pages are marked "firebugged.closed".

Finally, Firebug 1.4 does not have a way to view the annotations or to
remove individual annotation. You can remove all of the current
annotations by using Firebug status bar icon right click menu "Off for
all pages".

Hope this helps,
jjb

It helps a bit but will this mean debuggers and catch all errors will
trigger the
Firebug window to open? I have grown quite used to that behavior and am
always
at a loss when I open Firebug and there is nothing in the console.

I make some changes to the code and reload and the app doesn't load but it
takes a
while for me to realize that it's because I made syntax error in my last
change and there
is no longer any indication of this from Firebug (error logged or Firebug
popping up).

Please don't make the application friendly to casual users at the expense of
long time,
continuous use application developers.

I don't care how many resources it uses Firebug is no use to me if it's not
ready to use
all the time at the drop of a hat. If some weird bug occurs I want the full
logs available
regardless of whether I had Firebug open or not.

It's a question of whether Firebug wants to be web page developer friendly
or web
application (RIA) developer friendly.

On Fri, Jul 3, 2009 at 4:53 PM, John J Barton
<johnjbar...@johnjbarton.com>wrote:

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

I don't understand what you are saying.  If you can describe the
problem in a step by step fashion using the words in the Firebug user
interface, I have a better chance to get it.

That sounds like a bug to me. Certainly not part of any design.

There is no such plan, and nothing in the 1.4 design targets casual
users. On the contrary we make special efforts to make Firebug useful
for routine work. But different sets of users have different kinds of
routine work. We are not willing to design for a single routine.

Every development effort has to make trade-offs. The biggest source of
tradeoffs in 1.4 is simply that we don't have enough full time
developers. Therefore we make the choice to remove code as much as
possible.  That is why we do not support the 1.3 permissions based
white/black list mechanism.

Sounds like you should run with
  Firebug Status Bar Icon "On for all pages"

There is no such question and this was never debated. We have no
intention of making any such choice.  On the contrary if you go back
an try Firebug 1.0 on any modern web app I think you will see that we
have done quite a lot of work to make Firebug successful at larger
scale.

In 1.4 in particular we added features and improved the performance of
the net panel and script panel specifically to deal with scale.  There
is more than can be done; I expect the scale of web apps to continue
to grow and Firebug has to evolve to deal with it.

jjb