Whitelist/Blacklist support in Firebug 1.4

[John J Barton]

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

[Brian Di Palma]

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. 

[johnjbarton]

On Jul 4, 8:26 am, Brian Di Palma <off...@gmail.com> wrote:
> 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 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.

>
> 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).

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

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

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.

>
> 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.

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

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

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