New Activation Model

27 views
Skip to first unread message

Greg Beddow

unread,
Jun 30, 2009, 5:15:33 PM6/30/09
to fir...@googlegroups.com
Apologies in advance if this was already covered somewhere in the recent threads:

I’m using Firefox 3.5 (final) and Firebug 1.4.0b3.

A very common workflow for me, and I suspect a lot of developers, is to have Firebug open (in-browser) for a (local) site I’m developing, then make a change, say in some javascript code, come back to Firefox, clear its cache so it gets the change, then reload the page.

Maybe I’m missing some obvious Firebug setting, but for me, the page reload closes the Firebug window (why?), forcing me to reopen it, then I must load the page a *second* time before I’m finally debugging my changed code.

Greg Beddow

johnjbarton

unread,
Jun 30, 2009, 7:45:07 PM6/30/09
to Firebug
Greg,

You should just be able to go to Firefox and hit control-F5. That will
reload the page without reading from the cache. Firebug will not
close.

If FIrebug closes, then it is a bug. We've not heard of this before,
its not the way it should work.

One thing to check:
Either: about:config then type "firebug" to see if any settings are
not defaults.
Or: Firebug ICon menu > Options > reset all options.

Just in case something from 1.3 is left around.

jjb

Tama

unread,
Jun 30, 2009, 10:06:40 PM6/30/09
to Firebug
I too have been looking for an option to keep the FB pane open like it
did pre FF 3.5 using 1.5X.0a06 (I was using 1.4... but I thought this
might've been a bug so upgrade to 1.5...).

It's either one or both of these two things

1. The pane now closes when you navigate to a new page. Meaning you
always have to reopen the pane and then refresh the page because of
#2.
2. The pane doesn't log anything until it's open, even when the site
has been activated.

This basically means whenever I click a link to a new page on my dev
site I have to open the firebug page then click refresh. Which doesn't
actually work on some pages (e.g. logout).

johnjbarton

unread,
Jun 30, 2009, 11:02:02 PM6/30/09
to Firebug


On Jun 30, 7:06 pm, Tama <tama.pugs...@gmail.com> wrote:
> I too have been looking for an option to keep the FB pane open like it
> did pre FF 3.5 using 1.5X.0a06 (I was using 1.4... but I thought this
> might've been a bug so upgrade to 1.5...).
>
> It's either one or both of these two things
>
> 1. The pane now closes when you navigate to a new page. Meaning you
> always have to reopen the pane and then refresh the page because of
> #2.

The result when you navigate to a new page on a different domain,
firebug closes. It should do that in 1.3 as well unless the new domain
is one pre-selected by you.

> 2. The pane doesn't log anything until it's open, even when the site
> has been activated.

I don't understand what you are saying, but Firebug has to be active
when the page is loaded. This is true in 1.3 as well. However 1.3
automatically reloaded if you opened Firebug. Some people hated that
because they just wanted to use the CSS/HTML features, not the net/
script/console and did not want to wait for the reload.

>
> This basically means whenever I click a link to a new page on my dev
> site I have to open the firebug page then click refresh. Which doesn't
> actually work on some pages (e.g. logout).

? what is logout?
jjb

HIghway of Life

unread,
Jul 1, 2009, 5:44:13 AM7/1/09
to Firebug
On my development site (for example), the logout screen causes Firebug
to close down. I have to re-activate Firebug every time I login after
logging out.

- Highway of Life
Software Engineer

johnjbarton

unread,
Jul 1, 2009, 11:21:38 AM7/1/09
to Firebug
Firebug does not know about your logout. It only knows about URLs.

jjb

jjj

unread,
Jul 1, 2009, 2:33:45 PM7/1/09
to Firebug
re: #2

This new activation model is NOT workflow friendly for a web-dev, as I
often browse sites with the panel open, and want to see what they've
loaded WITHOUT hitting control-5. I can't keep the firebug window
open all the time, and it looks as if the only way to keep track of
net requests (as in the old model) is to keep the panel open.

Even telling firebug to 'enable all panels' and 'on for all pages'
will cause it to not capture net requests when the panel is minimized,
instead display this cryptic error message:

'Net panel activated. Any requests while the net panel is inactive are
not shown.'

Sure enough, it didn't log any net requests when the panel was
minimized. This is a regression issue and VERY annoying, as reloading
a page with control-f5 isn't an option for monitoring ajax requests
that have already happened.

Thanks,
J


On Jun 30, 8:02 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:

Trevan Richins

unread,
Jul 1, 2009, 2:50:24 PM7/1/09
to fir...@googlegroups.com
I didn't care for the activation model at the very beginning, but they've fixed a bunch of bugs related to it. Now, it is pretty decent for me. When I'm browsing the web to see what others are doing, marking "on for all pages" works perfectly. When I'm developing, most of my pages have been activated previously so they are activated the next time. I still mistakenly deactivate firebug instead of minimize it and that causes me grief, but I'm getting used to it. So, for those that are up in arms against it, just use it for a bit. It remembers the pages that you have previously activated firebug on. It attempts to keep firebug on in the same domain if it is already been open (I've seen some issues with this but never been able to reliably reproduce it so haven't filed a bug on it).

HIghway of Life

unread,
Jul 1, 2009, 3:31:37 PM7/1/09
to Firebug
On Jul 1, 8:21 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> Firebug does not know about your logout. It only knows about URLs.
>
> jjb
Right, but the point is that it's failing, whereas on 1.3, it never
failed here. Is it part of the new 'activation model' that is causing
it to fail (disable/turn off)?

Tama

unread,
Jul 1, 2009, 3:45:19 PM7/1/09
to Firebug
My problem was clicking the X to minimize Firebug as I have been for
the past 2-3 years. Clicking minimize has solved most of my
frustrations.

Using X to close Firebug makes sense UI-wise but no sense when version
1.3 used it to minimize.

Adding a notification the first time you click X saying "Did you
realise you have turned Firebug off? Use the minimize arrow, if you
would like Firebug to continue when minimized".

Luke Maurer

unread,
Jul 1, 2009, 3:56:18 PM7/1/09
to Firebug


On Jul 1, 11:50 am, Trevan Richins <TRich...@omniture.com> wrote:
> I still mistakenly deactivate firebug instead of minimize it and that causes me grief, but I'm getting used to it.

I wouldn't call that "mistaken," I'd call it perfectly reasonable. How
many UIs do you know that tie a background process like Ajax
monitoring inextricably to whether a certain window is open or not?
And by well-understood convention, if you "close" a window but the app
has a little icon in the bottom-right, it's still doing stuff in the
background (think of IM clients and the system tray). So there's every
reason for a user (*especially* those new users that the new
activation model is supposed to cater to) not to pay attention to the
difference between minimizing and closing - close means "get this bit
of UI out of the way," and minimize means "get it mostly out of the
way."

In short, the little X does not mean deactivate, it means close.
Having it do something other than close the window is unintuitive
*and* counterproductive.

> So, for those that are up in arms against it, just use it for a bit.  It remembers the pages that you have previously activated firebug on.  It attempts to keep firebug on in the same domain if it is already been open (I've seen some issues with this but never been able to reliably reproduce it so haven't filed a bug on it).

But this is always exactly the problem with software that tries to be
clever about what the user wants. It never quite works out, and the
user ends up spending more time working around the software's mistakes
than was ever saved by the cleverness to begin with.

- Luke

johnjbarton

unread,
Jul 1, 2009, 4:14:59 PM7/1/09
to Firebug


On Jul 1, 11:33 am, jjj <jason31...@gmail.com> wrote:
> re: #2
>
> This new activation model is NOT workflow friendly for a web-dev, as I
> often browse sites with the panel open, and want to see what they've
> loaded WITHOUT hitting control-5.  I can't keep the firebug window
> open all the time, and it looks as if the only way to keep track of
> net requests (as in the old model) is to keep the panel open.

For this use, I suggest using "open for all pages" (on the status bar
icon right click menu) and "minimize" the [_] icon in the upper right
corner.

>
> Even telling firebug to 'enable all panels' and 'on for all pages'
> will cause it to not capture net requests when the panel is minimized,

Under the settings I expect all net requests to be logged. If you have
a case where it fails we will fix it.

jjb

johnjbarton

unread,
Jul 1, 2009, 4:16:58 PM7/1/09
to Firebug


On Jul 1, 12:31 pm, HIghway of Life <highwayofl...@gmail.com> wrote:
> On Jul 1, 8:21 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:> Firebug does not know about your logout. It only knows about URLs.
>
> > jjb
>
> Right, but the point is that it's failing, whereas on 1.3, it never
> failed here. Is it part of the new 'activation model' that is causing
> it to fail (disable/turn off)?

Unfortunately I am not able to see the URLs in your browser from over
here. So I cannot tell if this is a bug or not.

jjb

johnjbarton

unread,
Jul 1, 2009, 4:21:23 PM7/1/09
to Firebug


On Jul 1, 12:56 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> On Jul 1, 11:50 am, Trevan Richins <TRich...@omniture.com> wrote:
>
> > I still mistakenly deactivate firebug instead of minimize it and that causes me grief, but I'm getting used to it.
>
> I wouldn't call that "mistaken," I'd call it perfectly reasonable. How
> many UIs do you know that tie a background process like Ajax
> monitoring inextricably to whether a certain window is open or not?

I don't what this has to do with Firebug.

> And by well-understood convention, if you "close" a window but the app
> has a little icon in the bottom-right, it's still doing stuff in the
> background (think of IM clients and the system tray). So there's every
> reason for a user (*especially* those new users that the new
> activation model is supposed to cater to) not to pay attention to the
> difference between minimizing and closing - close means "get this bit
> of UI out of the way," and minimize means "get it mostly out of the
> way."

I think Firebug user will get the hang of it pretty fast, they are are
a smart group.

>
> In short, the little X does not mean deactivate, it means close.
> Having it do something other than close the window is unintuitive
> *and* counterproductive.

I'm not sure what distinction you are making here. If Firebug is open
in the browser and you close it, it is not active for the browser tab.
That seem intuitive to me.

>
> > So, for those that are up in arms against it, just use it for a bit.  It remembers the pages that you have previously activated firebug on.  It attempts to keep firebug on in the same domain if it is already been open (I've seen some issues with this but never been able to reliably reproduce it so haven't filed a bug on it).
>
> But this is always exactly the problem with software that tries to be
> clever about what the user wants. It never quite works out, and the
> user ends up spending more time working around the software's mistakes
> than was ever saved by the cleverness to begin with.

If you have specific problems I would like to hear about them.

jjb

HIghway of Life

unread,
Jul 1, 2009, 4:40:43 PM7/1/09
to Firebug
On Jul 1, 1:16 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> Unfortunately I am not able to see the URLs in your browser from over
> here.  So I cannot tell if this is a bug or not.
>
> jjb

http://highwayoflife.net/jing/Firebug_Activation_Issues.swf
One thing I didn't catch in this screencast was that each time I
logged in, it was off, I would activate firebug, next login screen it
turned off again.

Hope that helps. Thanks!!

HIghway of Life

unread,
Jul 1, 2009, 4:48:53 PM7/1/09
to Firebug
Cross-posting, but here's hoping it will help others.
Installing Firebug 1.5a7 fixed the issue with Firebug turning on and
off randomly on a domain.
http://getfirebug.com/releases/firebug/1.5X/

jjj

unread,
Jul 1, 2009, 8:41:32 PM7/1/09
to Firebug
I tried this approach - firebug will pop open every time and I click
on the X - because I want that window closed - but the functionality
enabled. The firebug icon turns grey, and disables it.

Tell me how I can keep the network monitoring active while keeping the
network panel closed all the time until I click on the icon to open it
- ala previous versions?

>> Even telling firebug to 'enable all panels' and 'on for all pages'
>> will cause it to not capture net requests when the panel is minimized,

>Under the settings I expect all net requests to be logged. If you have
>a case where it fails we will fix it.

Right now, when repliyng via Google Groups - i have enable all panels
and on for all pages. I can hit control-n and guess what? the
firebug icon is greyed out. Sounds like you guys dropped the ball on
that one.

jjj

unread,
Jul 1, 2009, 8:47:36 PM7/1/09
to Firebug
This even happens with 1.5x.0a07 - I turned it "on for all pages", and
the checkbox is checked. I'm at the google groups page (http://
groups.google.com/group/firebug/browse_thread/thread/af951e7538f2dde2?
hl=en). I even have the net panel open as i typing this, and can hit
control-n and the firebug icon is disabled.

Tell me again how that's not broken?

johnjbarton

unread,
Jul 1, 2009, 9:03:59 PM7/1/09
to Firebug


On Jul 1, 5:41 pm, jjj <jason31...@gmail.com> wrote:
> I tried this approach - firebug will pop open every time and I click
> on the X - because I want that window closed - but the functionality
> enabled.  The firebug icon turns grey, and disables it.

Sorry I don't understand what you are saying.

>
> Tell me how I can keep the network monitoring active while keeping the
> network panel closed all the time until I click on the icon to open it
> - ala previous versions?

Use minimize for this [_] icon in the upper right corner.

>
> >> Even telling firebug to 'enable all panels' and 'on for all pages'
> >> will cause it to not capture net requests when the panel is minimized,
> >Under the settings I expect all net requests to be logged. If you have
> >a case where it fails we will fix it.
>
> Right now, when repliyng via Google Groups - i have enable all panels
> and on for all pages.  I can hit control-n and guess what?  the
> firebug icon is greyed out.  Sounds like you guys dropped the ball on
> that one.

What does control-n do? I've never used it.
jjb

johnjbarton

unread,
Jul 1, 2009, 9:05:20 PM7/1/09
to Firebug


On Jul 1, 5:47 pm, jjj <jason31...@gmail.com> wrote:
> This even happens with 1.5x.0a07 - I turned it "on for all pages", and
> the checkbox is checked.  I'm at the google groups page (http://
> groups.google.com/group/firebug/browse_thread/thread/af951e7538f2dde2?
> hl=en).  I even have the net panel open as i typing this, and can hit
> control-n and the firebug icon is disabled.
>
> Tell me again how that's not broken?

control-n is not a Firebug operation, so I don't know what to expect
if you use that key combo.

jjb

jjj

unread,
Jul 1, 2009, 9:33:13 PM7/1/09
to Firebug
Oh, you're right. Here's a test case for you to try:

Open firebug in the webpage of your choosing
Right click and enable 'on for all webpages'
Close firebug by clicking on [x]
Now go to FIREFOX->File->New Window


Result: Firebug is disabled and forgets the 'on for all webpages'
setting.

Perhaps the problem is that the [x] button in the firebug console
window will reset your setting for the checked 'on for all pages'?

jjj

unread,
Jul 1, 2009, 9:41:31 PM7/1/09
to Firebug
Sorry, let me rephrase that.

Since firebug is an "add-on" for Firefox, this keyboard accelerator is
actually "Ctrl+N" (Or otherwise via File->New Window). Perhaps you're
forgetting that firebug runs in Firefox? Therefore any accelerator
keyboard commands that the add-on "overloads" or "replaces" should be
firebug's responsibility.

Perhaps you should try a simple test-case instead of complaining that
"Ctrl+N" is not part of firebug, and instead try to understand that
its a regression design decision, and with that decision, there is no
affordance in the new version to 1.) match previous firebug UI
behaviors and expecations and 2.) Firefox plugin standards for
enabling/disabling an add on - Perhaps evaluate how the flashblock add-
on functions for a definition of enabled/disabled?

jjj


On Jul 1, 6:05 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:

johnjbarton

unread,
Jul 1, 2009, 11:31:59 PM7/1/09
to Firebug


On Jul 1, 6:41 pm, jjj <jason31...@gmail.com> wrote:
> Sorry, let me rephrase that.
>
> Since firebug is an "add-on" for Firefox, this keyboard accelerator is
> actually "Ctrl+N" (Or otherwise via File->New Window).  Perhaps you're
> forgetting that firebug runs in Firefox?  Therefore any accelerator
> keyboard commands that the add-on "overloads" or "replaces" should be
> firebug's responsibility.

To the best of my knowledge Firebug does not overload or replace
control n.

>
> Perhaps you should try a simple test-case instead of complaining that
> "Ctrl+N" is not part of firebug, and instead try to understand that
> its a regression design decision, and with that decision, there is no
> affordance in the new version to 1.) match previous firebug UI
> behaviors and expecations and 2.) Firefox plugin standards for
> enabling/disabling an add on - Perhaps evaluate how the flashblock add-
> on functions for a definition of enabled/disabled?

Since Firebug did not overload or replace control n in the past or
present I don't now how to help you.

jjb

jjj

unread,
Jul 2, 2009, 11:20:51 AM7/2/09
to Firebug
Then tell me why turning 'on for all pages' causes firebug to fail to
turn on while browsing in firefox?

Can you confirm that by turning 'on for all pages', firebug stays on
for every single page until you explicitly turn it off?

johnjbarton

unread,
Jul 2, 2009, 11:49:54 AM7/2/09
to Firebug


On Jul 2, 8:20 am, jjj <jason31...@gmail.com> wrote:
> Then tell me why turning 'on for all pages' causes firebug to fail to
> turn on while browsing in firefox?

I don't know why this does not work for you. It works for me.

>
> Can you confirm that by turning 'on for all pages', firebug stays on
> for every single page until you explicitly turn it off?

I can confirm that Firebug will stay on for me if I select "on for all
pages" then visit a set of completely different sites.

Here is are the specifics:
1) Open Firefox 3.5 with Firebug 1.5a7.
2) Right click Firebug Icon, select On for all Web Pages.
3) Open www.google.com firebug is up
4) search for "foo" and click on the first result, http://en.wikipedia.org/wiki/Foo;
Firebug is up.
5) type http://www.ibm.com into the location bar, hit enter. Firebug
is up

Does this work for you?

Based on my tests and the fact that other users have used this option
successfully, it's my guess that the reason it fails for you is
related to some property of your environment. A simple and effective
test for this is create a new Firefox profile, install Firebug, and
restart.

jjb

jjj

unread,
Jul 2, 2009, 3:47:10 PM7/2/09
to Firebug
No, this test case does not take into account the following failures:
1.) the firebug panel fails to be enabled when launching new firefox
windows by going to File->New Window in Firefox. Defect.

2.) the firebug panel-reopens every time you navigate to a new page.
There is no configuration affordance or set of options that will allow
firebug to be enabled (i.e. script, network, or other data
monitoring), but not UI-invasive when not needed. This is a regression
design decision.

A user story would be: I really want to have firebug monitoring all
network requests but not be visible until I determine there has been a
need to view the webpage, for instance to check on AJAX requests, or
some similar need to view all the requests a webpage has made from the
first load to when the panel has been opened.



Thanks,
J


On Jul 2, 8:49 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 2, 8:20 am, jjj <jason31...@gmail.com> wrote:
>
> > Then tell me why turning 'on for all pages' causes firebug to fail to
> > turn on while browsing in firefox?
>
> I don't know why this does not work for you. It works for me.
>
>
>
> > Can you confirm that by turning 'on for all pages', firebug stays on
> > for every single page until you explicitly turn it off?
>
> I can confirm that Firebug will stay on for me if I select "on for all
> pages" then visit a set of completely different sites.
>
> Here is are the specifics:
> 1) Open Firefox 3.5 with Firebug 1.5a7.
> 2) Right click Firebug Icon, select On for all Web Pages.
> 3) Openwww.google.comfirebug is up
> 4) search for "foo" and click on the first result,http://en.wikipedia.org/wiki/Foo;
> Firebug is up.
> 5) typehttp://www.ibm.cominto the location bar, hit enter. Firebug

johnjbarton

unread,
Jul 2, 2009, 5:16:40 PM7/2/09
to Firebug
I assume from your reply that you found my test sequence to work
properly on your machine. That's good. You are welcome to propose your
own test sequence either here or on the bug report. When you do I will
try it.
jjb
> > 3) Openwww.google.comfirebugis up
> > 4) search for "foo" and click on the first result,http://en.wikipedia.org/wiki/Foo;
> > Firebug is up.
> > 5) typehttp://www.ibm.comintothe location bar, hit enter. Firebug

sir_brizz

unread,
Jul 2, 2009, 5:33:41 PM7/2/09
to Firebug
I assumed his test case was pretty self explanatory.

1) Right click Firebug, check "On for all pages".
2) Hit Ctrl-N (or whatever your key combo for a new window is)
-- Firebug is not enabled on the ensuing home page load and "On for
all pages" is not checked.

In his other scenario:
1) Right click Firebug, check "On for all pages".
2) Minimize Firebug.
3) Browse to another page on any domain.
-- Firebug panel pops open instead of staying minimized.
> > > 5) typehttp://www.ibm.comintothelocation bar, hit enter. Firebug

sir_brizz

unread,
Jul 2, 2009, 5:48:10 PM7/2/09
to Firebug
It also seems that once you check "On for all pages" on a browser
session, thre is no way to disable it (unchecking doesn't work, you
can "close" firebug, but it opens again on the next page load).
> > > > 5) typehttp://www.ibm.comintothelocationbar, hit enter. Firebug

johnjbarton

unread,
Jul 2, 2009, 5:50:44 PM7/2/09
to Firebug


On Jul 2, 2:33 pm, sir_brizz <bj.car...@gmail.com> wrote:
> I assumed his test case was pretty self explanatory.
>
> 1) Right click Firebug, check "On for all pages".
> 2) Hit Ctrl-N (or whatever your key combo for a new window is)
> -- Firebug is not enabled on the ensuing home page load and "On for
> all pages" is not checked.

Yes thanks this is a bug.

>
> In his other scenario:
> 1) Right click Firebug, check "On for all pages".
> 2) Minimize Firebug.
> 3) Browse to another page on any domain.
> -- Firebug panel pops open instead of staying minimized.

No, this does not happen for me.
> > > > 5) typehttp://www.ibm.comintothelocationbar, hit enter. Firebug

Highway of Life

unread,
Jul 2, 2009, 6:04:10 PM7/2/09
to Firebug
On Jul 2, 2:50 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 2, 2:33 pm, sir_brizz <bj.car...@gmail.com> wrote:
> > In his other scenario:
> > 1) Right click Firebug, check "On for all pages".
> > 2) Minimize Firebug.
> > 3) Browse to another page on any domain.
> > -- Firebug panel pops open instead of staying minimized.
>
> No, this does not happen for me.

Does not happen for me either, but I did see that happen on a co-
workers computer a week ago. I told him to upgrade to Firebug 1.5 and
I do not believe he is having this issue any longer.

- Highway of LIfe

sir_brizz

unread,
Jul 2, 2009, 6:07:58 PM7/2/09
to Firebug


On Jul 2, 3:50 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > In his other scenario:
> > 1) Right click Firebug, check "On for all pages".
> > 2) Minimize Firebug.
> > 3) Browse to another page on any domain.
> > -- Firebug panel pops open instead of staying minimized.
>
> No, this does not happen for me.
>

You're right, this is the correct use-case:

1) Right click Firebug, check "On for all pages".
2) CLOSE Firebug (with the 'x').
3) Open a new tab
-- Firebug panel pops open instead of staying minimized.

>
>

johnjbarton

unread,
Jul 2, 2009, 7:54:49 PM7/2/09
to Firebug


On Jul 2, 3:07 pm, sir_brizz <bj.car...@gmail.com> wrote:
...
> You're right, this is the correct use-case:
>
> 1) Right click Firebug, check "On for all pages".
> 2) CLOSE Firebug (with the 'x').

That would be "Deactivate FIrebug for this page" ;-)

> 3) Open a new tab
> -- Firebug panel pops open instead of staying minimized.

It wasn't minimized so it won't stay minimized. It was deactivated on
a page, then the tab obeys "On for all pages".

jjb



sir_brizz

unread,
Jul 2, 2009, 8:00:55 PM7/2/09
to Firebug
Perhaps.

1) Are you suggesting that Firebug should keep a blacklist of disabled
sites when "On for all sites" is checked? Currently it doesn't, I
believe that is the correct behavior.

2) In the case where "On for all pages" is checked, the meaning of
"Close" and "Minimize" blurs almost entirely. Close could just mean
"get out of my way" as much as minimize could.

Anyway, I believe the appropriate behavior should be that the panel is
up on the following page only if it was up on the page previous. If
the panel is not showing for any reason on the originating page, it
should not pop up on the resulting page, either. This is certainly one
of those cases I was talking about before when I said that "How should
[some process] function?" question is way too easy to bring up with
the new activation model. In 1.3, or with an even more flexible
whitelist/blacklist model, there would simply be no question what
should happen in this case.

johnjbarton

unread,
Jul 2, 2009, 8:26:21 PM7/2/09
to Firebug
The question here isn't what should happen when you go to a new tab.
The "on for all pages" means Firebug should be on.

The question is what should the [X] do when "On for all pages " is
true.

Probably it should be disabled. After all the UI promised "on for all
pages", not "on for all but ones you click the [X]" Does that make
sense?

I think the clarity of the 1.3 model is partly because most people
actually did not understand it. If you set the panels enabled once and
focused on the site controls, then you probably were lucky. Else not:
the 1.3 model coupled the panel activation, site activation, and
placement (detached, minimized, in browser) So if you start changing
these other settings you can get mixed up pretty quick.

The 1.4 model is much clearer. The activation, placement, and panel
enablement are all separate. If you notice in all of these
discussions we did not once get into panel enable/disable. That was a
huge issue in 1.3. The placement part of the UI (the [_] [-][X]
controls) was added later in the design and we have less feedback on
them. I do not think we have all of the UI for these prefect by any
means, but its also just not that bad.

jjb

sir_brizz

unread,
Jul 2, 2009, 10:21:47 PM7/2/09
to Firebug
I'm just unsure what clarity was actually lost in the 1.3 model. If
you had enabled Firebug for a domain, then it was on on that domain.
You could have expanded this by introducing the bug lit/unlit design
you have for 1.4 now to show whether Firebug was active on the page or
not. Who cares what the panel is doing? If you want to know if Firebug
is on, just look at the bug. (As a sidenote, I have no clue about the
panel being detached as my screen space doesn't allow for that to be
done well, but it seems to me that, like Safari 4, this could have
just been done on the active page in Firefox)

As before, I realize the current model makes some sense, I just don't
see it as a worthwhile change over what we had. As someone who heavily
prefers the 1.2 design to this day, I would much prefer just being
able to have firebug either always on or always off and then have
domain settings for the opposite action to occur.

I realize all of this isn't going to go anywhere, the core development
team is happy with the activation model regardless of what any
individual person wants, so nothing is likely to change as far as how
the model is functionally.

So roping this all back in to what can actually happen for the current
design, the X is confusing in "On for all pages" mode. I understand
that it isn't doing the blacklisting of the domain, though that might
be a nice feature, but, in my opinion, the state of the panel itself
(showing or hidden) should stay static across all pages when the
option is set.

On another note, I don't really get the "Off for all pages" option. Is
that for debugging? Or does it change your per-domain settings in some
way? Because unchecking "On for all pages" should just revert to your
original settings.

The thing I dislike most about 1.4 is that Activation is linked sooooo
tightly to the panel displaying. It doesn't feel like these things are
separate at all anymore, so it feels like it is "Panel showing,
Firebug active. Panel not showing, Firebug inactive" (despite the fact
that that is not quite how it works) and I hate that to extreme
levels.

Brade

unread,
Jul 3, 2009, 8:21:06 AM7/3/09
to Firebug
On Jul 2, 8:26 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:

> The 1.4 model is much clearer.


Denial ain't just a river in Egypt.

johnjbarton

unread,
Jul 3, 2009, 12:39:18 PM7/3/09
to Firebug
Ok, fine I take it back:
The 1.4 model is what it is. Let's try to figure out how to explain
how it works or tweak it to be better because no one wants to develop
and maintain an alternative.

jjb

johnjbarton

unread,
Jul 3, 2009, 12:55:31 PM7/3/09
to Firebug


On Jul 2, 7:21 pm, sir_brizz <bj.car...@gmail.com> wrote:
> I'm just unsure what clarity was actually lost in the 1.3 model. If
> you had enabled Firebug for a domain, then it was on on that domain.
> You could have expanded this by introducing the bug lit/unlit design
> you have for 1.4 now to show whether Firebug was active on the page or
> not. Who cares what the panel is doing? If you want to know if Firebug
> is on, just look at the bug. ...

The Firebug icon is orange when the optional panels Console/Script/Net
are operating. This is the same in Firebug 1.3 and 1.4.

> As before, I realize the current model makes some sense, I just don't
> see it as a worthwhile change over what we had. As someone who heavily
> prefers the 1.2 design to this day, I would much prefer just being
> able to have firebug either always on or always off and then have
> domain settings for the opposite action to occur.

Now you are reminding me how much time I've wasted on this stuff.

>
> I realize all of this isn't going to go anywhere, the core development
> team is happy with the activation model regardless of what any
> individual person wants, so nothing is likely to change as far as how
> the model is functionally.

I would not say "happy", more like "allowing deactivation was a waste
of time". In retrospect I think we should never have implemented
activation at all. Rather we should have just made Firebug "on", end
of story. If it makes using Firefox for your gmail impossible, sorry,
we do debuggers not email clients. That would have made 1.2 hugely
unpopular and cut the number of users by a large fraction and possibly
prevent Mozilla from contributing to the project. On the other hand, I
would been able to concentrate on things that make more difference to
debugging.

>
> So roping this all back in to what can actually happen for the current
> design, the X is confusing in "On for all pages" mode. I understand
> that it isn't doing the blacklisting of the domain, though that might
> be a nice feature, but, in my opinion, the state of the panel itself
> (showing or hidden) should stay static across all pages when the
> option is set.

Yes we could have On For All Pages obey the black list settings. But
I'm not sure that would be less confusing.

>
> On another note, I don't really get the "Off for all pages" option. Is
> that for debugging? Or does it change your per-domain settings in some
> way? Because unchecking "On for all pages" should just revert to your
> original settings.

Unchecking "On for all pages" stops whitelisting new pages. It does
not change any existing annotations.
"Off for all pages" clears the whitelist. So yes in fact it is a
debugging feature.

>
> The thing I dislike most about 1.4 is that Activation is linked sooooo
> tightly to the panel displaying. It doesn't feel like these things are
> separate at all anymore, so it feels like it is "Panel showing,
> Firebug active. Panel not showing, Firebug inactive" (despite the fact
> that that is not quite how it works) and I hate that to extreme
> levels.

"Panel not showing, Firebug active" is minimize.
Panel showing, Firebug inactive is not supported, correct.

jjb

sir_brizz

unread,
Jul 3, 2009, 1:19:16 PM7/3/09
to Firebug


On Jul 3, 10:55 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 2, 7:21 pm, sir_brizz <bj.car...@gmail.com> wrote:
> > I realize all of this isn't going to go anywhere, the core development
> > team is happy with the activation model regardless of what any
> > individual person wants, so nothing is likely to change as far as how
> > the model is functionally.
>
> I would not say "happy", more like "allowing deactivation was a waste
> of time". In retrospect I think we should never have implemented
> activation at all. Rather we should have just made Firebug "on", end
> of story. If it makes using Firefox for your gmail impossible, sorry,
> we do debuggers not email clients. That would have made 1.2 hugely
> unpopular and cut the number of users by a large fraction and possibly
> prevent Mozilla from contributing to the project. On the other hand, I
> would been able to concentrate on things that make more difference to
> debugging.

Well, I guess that is part of my confusion about 1.4. It seems an
extraordinary amount of time was spent on something that is hugely
complex and doesn't even really contribute to the core functionality
of Firebug. That's why I would have thought a more simple and flexible
system would have been adopted moving on from 1.3.

> > So roping this all back in to what can actually happen for the current
> > design, the X is confusing in "On for all pages" mode. I understand
> > that it isn't doing the blacklisting of the domain, though that might
> > be a nice feature, but, in my opinion, the state of the panel itself
> > (showing or hidden) should stay static across all pages when the
> > option is set.
>
> Yes we could have On For All Pages obey the black list settings. But
> I'm not sure that would be less confusing.

I don't really want that. I'd rather just have "If Firebug is not
showing and you go to another page, continue not showing Firebug". It
doesn't make sense to have it popping up and minimizing all over the
place. Currently there is no way to BOTH minimize and close Firebug
for a page when "On for all pages" is checked, therefore if I want
firebug to stay minimized and turn it off for a page, I can't.

> > On another note, I don't really get the "Off for all pages" option. Is
> > that for debugging? Or does it change your per-domain settings in some
> > way? Because unchecking "On for all pages" should just revert to your
> > original settings.
>
> Unchecking "On for all pages" stops whitelisting new pages. It does
> not change any existing annotations.
> "Off for all pages" clears the whitelist. So yes in fact it is a
> debugging feature.

Okay, this makes sense. But it is confusing, I wouldn't expect "Off
for all pages" to change domain settings based on what "On for all
pages" does (unless... does "Off for all pages" only disable domain
settings while it is checked?? If so, that's probably fine...)

> > The thing I dislike most about 1.4 is that Activation is linked sooooo
> > tightly to the panel displaying. It doesn't feel like these things are
> > separate at all anymore, so it feels like it is "Panel showing,
> > Firebug active. Panel not showing, Firebug inactive" (despite the fact
> > that that is not quite how it works) and I hate that to extreme
> > levels.
>
> "Panel not showing, Firebug active" is minimize.
> Panel showing, Firebug inactive is not supported, correct.

I wouldn't expect it to, really. I realize that it's possible to have
Firebug active and not showing, but based on the other functionality,
it doesn't seem like that would work.

>
> jjb

Nicolas Hatier

unread,
Jul 3, 2009, 1:34:23 PM7/3/09
to fir...@googlegroups.com

IMHO, with the latest bug fixes and enhancements (1.5X.0a8), the new activation model begins to be really usable and to make sense.

One further enhancement would be to keep the minimize state as it is currently and stop opening and minimizing spuriously... The minimize/un-minimize action should always be a manual one.

For instance, I have the "On for all pages" option set. I navigate to any url. I minimize Firebug. Then I click File/New on Firefox, and it opens a new window on my home page. Firebug is active (correct), but not minimized - the Firebug panel is shown (incorrect). Closing completely Firefox and opening it back will also show the Firebug panel, even if it was minimized before. I think that's not a wanted behavior.

Other example which shows a correct behavior: I still have "On for all pages" option set. I navigate to my dev site, and open the FIrebug panel. Then I type another URL, say www.google.com. Firebug panel stays open (correct). I minimize it, then go back to my dev site. Firebug stays minimized (still correct).

NH

travisa

unread,
Jul 3, 2009, 4:15:36 PM7/3/09
to Firebug
While activating Firebug and then refreshing the page to view requests
and responses will work on certain occasions, this is is not much of a
solution for content that varies upon refreshing.

Troubleshooting a malfunctioning ad running at a low percentage share
of voice is now impossible with Firebug under the new activation
model. As content becomes increasingly dynamic online, debugging
issues via refreshing will become a remotely viable option. You simply
will need to have been recording from the start, user-initiation after
the fact will just not cut it.

Please do not underestimate the size of the base of Firebug users that
need the plugin to be automatically recording on specific domains and
automatically disabled the rest of the time (or the inverse of this).
Firebug 1.4 and 1.5 (even with the bug fixes) are still useless for
this increasingly common purpose.

We now need a Firebug 1.3 for Firefox 3.5 (or at least an extension
that brings back the legacy domain whitelist/blacklist activation
model).

My apologies if this comes across as a bit harsh but this is honestly
the reality. I speak for many developers who have been feeling this
pain since updating to Firefox 3.5 and Firebug 1.4+.

-Travis

On Jul 3, 1:34 pm, Nicolas Hatier <nicolas.hat...@gmail.com> wrote:
> IMHO, with the latest bug fixes and enhancements (1.5X.0a8), the new
> activation model begins to be really usable and to make sense.
>
> One further enhancement would be to keep the minimize state as it is
> currently and stop opening and minimizing spuriously... The
> minimize/un-minimize action should always be a manual one.
>
> For instance, I have the "On for all pages" option set. I navigate to
> any url. I minimize Firebug. Then I click File/New on Firefox, and it
> opens a new window on my home page. Firebug is active (correct), but not
> minimized - the Firebug panel is shown (incorrect). Closing completely
> Firefox and opening it back will also show the Firebug panel, even if it
> was minimized before. I think that's not a wanted behavior.
>
> Other example which shows a correct behavior: I still have "On for all
> pages" option set. I navigate to my dev site, and open the FIrebug
> panel. Then I type another URL, saywww.google.com. Firebug panel stays

jjj

unread,
Jul 3, 2009, 7:15:07 PM7/3/09
to Firebug
Absolutely not. 'X' does not imply 'deactivate firebug for this
page. This is an incorrect user assumption and you are trying to make
Firebug 'outsmart the end user', when you never told the end user what
the hell you were doing.

jjj

Luke Maurer

unread,
Jul 3, 2009, 7:16:19 PM7/3/09
to Firebug
On Jul 3, 1:15 pm, travisa <tja...@gmail.com> wrote:
> We now need a Firebug 1.3 for Firefox 3.5 (or at least an extension
> that brings back the legacy domain whitelist/blacklist activation
> model).

Well, that's the good news in all this - JJB mentioned that FB1.4 has
hooks for just such an extension. So something tells me that it'll
only be a week or two before someone's thrown together a plugin to
restore the functionality.

(Maybe this is all a ploy to prod more people into learning the
extension API so more plugins will be developed? :-D )

- Luke

jjj

unread,
Jul 3, 2009, 7:20:15 PM7/3/09
to Firebug
Thank you Travis, I am in complete agreement with you on this.

You have a described a much better user story than I was able to
express, and I hope that the firebug team (including jjb) will take
this use-case when evaluating the effectiveness of the new model. I
only wish the devteam was more receptive to their users, instead of
assumptions about much it can outsmart the end-user in an attempt to
be helpful...

jjj

johnjbarton

unread,
Jul 3, 2009, 11:54:10 PM7/3/09
to Firebug


On Jul 3, 1:15 pm, travisa <tja...@gmail.com> wrote:
> While activating Firebug and then refreshing the page to view requests
> and responses will work on certain occasions, this is is not much of a
> solution for content that varies upon refreshing.

The *only* difference between Firebug 1.3 and 1.4 in this regard is
that 1.3 automatically reloaded the page without your action. Some
users do not like this. They do not want Firebug to try to be too
smart. So in 1.4 you have to reload manually.

>
> Troubleshooting a malfunctioning ad running at a low percentage share
> of voice is now impossible with Firebug under the new activation
> model. As content becomes increasingly dynamic online, debugging
> issues via refreshing will become a remotely viable option. You simply
> will need to have been recording from the start, user-initiation after
> the fact will just not cut it.

Ok, fine, reload the page. 1.4 does not do it automatically, you have
to do it manually.

>
> Please do not underestimate the size of the base of Firebug users that
> need the plugin to be automatically recording on specific domains and
> automatically disabled the rest of the time (or the inverse of this).

Actually neither of us have any idea how many people use Firebug in
any particular way. But that does not matter because Firebug 1.4 of
course supports this use model.

> Firebug 1.4 and 1.5 (even with the bug fixes) are still useless for
> this increasingly common purpose.

If you have specific test cases where Firebug fails to be activate,
please post them here or on the issue list.

>
> We now need a Firebug 1.3 for Firefox 3.5 (or at least an extension
> that brings back the legacy domain whitelist/blacklist activation
> model).

It's open source, go for it.

>
> My apologies if this comes across as a bit harsh but this is honestly
> the reality. I speak for many developers who have been feeling this
> pain since updating to Firefox 3.5 and Firebug 1.4+.

No, it's not reality, it's misunderstanding. You have to reload the
page manually. If you want to make the case for automatic reload,
please do so. We are listening to your input here as we have from the
beginning of Firebug 1.4 back in December.

jjb

johnjbarton

unread,
Jul 3, 2009, 11:59:21 PM7/3/09
to Firebug


On Jul 3, 4:15 pm, jjj <jason31...@gmail.com> wrote:
> Absolutely not.  'X' does not imply 'deactivate firebug for this
> page.  This is an incorrect user assumption and you are trying to make
> Firebug 'outsmart the end user', when you never told the end user what
> the hell you were doing.

(I wonder where this "smart" thing came from anyway).

If you click the [X] on the the Firebug user interface, Firebug will
remove the URL from the whitelist, put the URL on the blacklist, and
suspend (hide the UI and turn off the listeners).

For me this is "deactivate Firebug for this page". What do you want
to call it?

When a user clicks the [X], Firebug closes. It does not try to
outsmart them, it just closes. I think that most users expect when
they hit [X], a program closes. If you have a better icon, let us
know.

jjb

johnjbarton

unread,
Jul 4, 2009, 12:05:31 AM7/4/09
to Firebug


On Jul 3, 4:16 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> On Jul 3, 1:15 pm, travisa <tja...@gmail.com> wrote:
>
> > We now need a Firebug 1.3 for Firefox 3.5 (or at least an extension
> > that brings back the legacy domain whitelist/blacklist activation
> > model).
>
> Well, that's the good news in all this - JJB mentioned that FB1.4 has
> hooks for just such an extension. So something tells me that it'll
> only be a week or two before someone's thrown together a plugin to
> restore the functionality.

Some already has been working on this. Look back through this
newsgroup.

johnjbarton

unread,
Jul 4, 2009, 12:10:41 AM7/4/09
to Firebug


On Jul 3, 4:20 pm, jjj <jason31...@gmail.com> wrote:
> Thank you Travis, I am in complete agreement with you on this.
>
> You have a described a much better user story than I was able to
> express, and I hope that the firebug team (including jjb) will take
> this use-case when evaluating the effectiveness of the new model. I
> only wish the devteam was more receptive to their users, instead of
> assumptions about much it can outsmart the end-user in an attempt to
> be helpful...

Well Travis' user story was about a mis-communications. So let me just
say it again:

In 1.4 the first time you activate a page (or domain in the Activate
Same Origin option), Firebug will not have been listening at the load.
So you have to reload. After that first time, Firebug will be active
on load and you don't need to reload.

As for "more receptive", I'll tell you the dev team is pretty unhappy
that you waited until the week before release to start this nonsense.
If you want a voice in the design of Firebug, get involved when we are
doing the design, not when we ship.

jjb

johnjbarton

unread,
Jul 4, 2009, 12:20:16 AM7/4/09
to Firebug


On Jul 3, 10:19 am, sir_brizz <bj.car...@gmail.com> wrote:
...
> Well, I guess that is part of my confusion about 1.4. It seems an
> extraordinary amount of time was spent on something that is hugely
> complex and doesn't even really contribute to the core functionality
> of Firebug. That's why I would have thought a more simple and flexible
> system would have been adopted moving on from 1.3.

Yes, I invested a huge amount of time: to get rid of the garbage that
was 1.3. I don't know where you get the idea that 1.4 activation is
hugely complex. It's less than 150 lines of code:
http://code.google.com/p/fbug/source/browse/branches/firebug1.4/content/firebug/firebug.js#3374

...
> > Yes we could have On For All Pages obey the black list settings. But
> > I'm not sure that would be less confusing.
>
> I don't really want that. I'd rather just have "If Firebug is not
> showing and you go to another page, continue not showing Firebug". It

So use "Off for all pages".

> doesn't make sense to have it popping up and minimizing all over the
> place. Currently there is no way to BOTH minimize and close Firebug
> for a page when "On for all pages" is checked, therefore if I want
> firebug to stay minimized and turn it off for a page, I can't.

? That combo would not make sense. Closed is "not active and not
showing". Minimized is "active and not showing". You can't have both.

jjb

sir_brizz

unread,
Jul 4, 2009, 1:22:24 AM7/4/09
to Firebug
On Jul 3, 10:20 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 3, 10:19 am, sir_brizz <bj.car...@gmail.com> wrote:
> ...
>
> > Well, I guess that is part of my confusion about 1.4. It seems an
> > extraordinary amount of time was spent on something that is hugely
> > complex and doesn't even really contribute to the core functionality
> > of Firebug. That's why I would have thought a more simple and flexible
> > system would have been adopted moving on from 1.3.
>
> Yes, I invested a huge amount of time: to get rid of the garbage that
> was 1.3. I don't know where you get the idea that 1.4 activation is
> hugely complex. It's less than 150 lines of code:http://code.google.com/p/fbug/source/browse/branches/firebug1.4/conte...
>

I don't mean that the code itself is entirely complex, I mean that
obviously more time and effort was spent on this issue than many other
issues in Firebug (tweaking and fixing issues) when many people
thought the previous model was fine with a little tweaking. I get it,
you don't agree. I just don't know where the idea that 1.3 was so
wildly hated came from, most of the talking I've seen on this list
since 1.3 was released are about 1.4 issues. I'm sure the 1.3 model
was disliked by some, byut how was it determined that that number was
or would be higher than those that would hate the 1.4 model?? I could
probably have made similar counter arguments about the 1.3 model
several months ago as you are making about the 1.4 model (that you
can't count the number of people complaining here as if they
represented all of the Firebug users) and so I can only assume that
the decision to change the activation model was a completely internal
one.

Also, in response to your comment a couple posts back about the team
being upset that people are complaining now as opposed to previously,
I think it only makes sense that a fraction of the people who read
this list are using the alphas, and only a fraction of those will talk
about anything in the alpha that isn't inherently broken. Lots of
people talked about and complained about the activation model during
the alpha period, but there wasn't a lot of response different from
what we are getting now.

> > > Yes we could have On For All Pages obey the black list settings. But
> > > I'm not sure that would be less confusing.
>
> > I don't really want that. I'd rather just have "If Firebug is not
> > showing and you go to another page, continue not showing Firebug". It
>
> So use "Off for all pages".

But I don't want it off all the time.

>
> > doesn't make sense to have it popping up and minimizing all over the
> > place. Currently there is no way to BOTH minimize and close Firebug
> > for a page when "On for all pages" is checked, therefore if I want
> > firebug to stay minimized and turn it off for a page, I can't.
>
> ? That combo would not make sense. Closed is "not active and not
> showing". Minimized is "active and not showing". You can't have both.

You're missing my point completely here.

Right click Firebug
Check "On for all pages"
Go to http://www.yahoo.com [Firebug panel opens]
Minimize Firebug
Go to http://www.google.com [Firebug remains minimized correctly]

At this point, what I WANT to do is keep Firebug "minimized" but
disable it for http://www.google.com, so I:

Click the bug
Click the [x]
Go to http://www.yahoo.com [Firebug panel opens incorrectly, in my
opinion]

Currently there is no way to change this behavior, and that is a
problem. In my opinion, if "On for all pages" is checked and the
Firebug panel is not displaying at all (whether it is minimized or
closed), it should not be showing on any subsequent page loads until
the bug is clicked again.

I think that just highlights one of the problems with this model, but
I'll leave that whining now. :p

>
> jjb

johnjbarton

unread,
Jul 4, 2009, 2:05:34 AM7/4/09
to Firebug


On Jul 3, 10:22 pm, sir_brizz <bj.car...@gmail.com> wrote:
...>
> You're missing my point completely here.

And I'll keep missing the point until you break it down in ways I can
understand. Oh wait you did:

>
> Right click Firebug
> Check "On for all pages"
> Go tohttp://www.yahoo.com[Firebug panel opens]
> Minimize Firebug
> Go tohttp://www.google.com[Firebug remains minimized correctly]
>
> At this point, what I WANT to do is keep Firebug "minimized" but
> disable it forhttp://www.google.com, so I:
>
> Click the bug

This is the UI operation for un-minimizing Firebug.

> Click the [x]

This is a bug: the [X] should be disabled.

> Go tohttp://www.yahoo.com[Firebug panel opens incorrectly, in my
> opinion]

But since you said "on for all pages", and "un-minimize" this is
working as designed.

>
> Currently there is no way to change this behavior, and that is a
> problem. In my opinion, if "On for all pages" is checked and the
> Firebug panel is not displaying at all (whether it is minimized or
> closed), it should not be showing on any subsequent page loads until
> the bug is clicked again.

In my opinion, "On for all pages" should be "on for all pages". You
should not be able to deactivate a page and close Firebug when the
option is set. The fact that you can mislead you about the character
of the option.

>
> I think that just highlights one of the problems with this model, but
> I'll leave that whining now. :p

And I think it just highlights a bug. It communicates one problem you
have in a way I can understand. Not one person in the time since I
have been working on 1.4 has ever reported this problem. You just did
and now I can fix it.

But once I fix it you will *not* be getting what you want. That is, I
am going prevent you from using "On for all pages" in a way you hoped
would be good for you. So I hope you will try 1.4b5 or 1.5a8 without
"On for all pages" and communicate -- in the same step-wise approach
-- what problems you have that make you want to use "on for all pages"
in funky ways.

jjb

sir_brizz

unread,
Jul 4, 2009, 2:12:05 AM7/4/09
to Firebug
Really I'm just wishing for a way that I could have "On for all pages"
and disable it for specific domains :) Being able to close it on one
domain is kind of like what I want (but obviously refreshing does it
in).

Anyway, I'm getting tired of complaining about the new activation
model. I can't see it ever working the way I would like to use it, so,
as in 1.3, I'll just work on getting accustomed to this inferior
(imo ;)) model.

On Jul 4, 12:05 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 3, 10:22 pm, sir_brizz <bj.car...@gmail.com> wrote:
> ...>
>
> > You're missing my point completely here.
>
> And I'll keep missing the point until you break it down in ways I can
> understand. Oh wait you did:
>
>
>
> > Right click Firebug
> > Check "On for all pages"
> > Go tohttp://www.yahoo.com[Firebugpanel opens]
> > Minimize Firebug
> > Go tohttp://www.google.com[Firebugremains minimized correctly]
>
> > At this point, what I WANT to do is keep Firebug "minimized" but
> > disable it forhttp://www.google.com, so I:
>
> > Click the bug
>
> This is the UI operation for un-minimizing Firebug.
>
> > Click the [x]
>
> This is a bug: the [X] should be disabled.
>
> > Go tohttp://www.yahoo.com[Firebugpanel opens incorrectly, in my

Rako

unread,
Jul 4, 2009, 7:50:28 AM7/4/09
to Firebug
Having read this discussion, I think there should be two options:
"On for all pages, except"
"Off for all pages, except"
This would be easy to understand. For both there would be an
exceptions-list, or a number of alternative lists.
Thus you could have alternative selection of sites or pages within the
sites and choose the selection you currently want.
To implement these, a small off-line settings program could be
written:
The user can create the selections before beginning with the on-line
tests. During the tests he could merely choose between the selections.
Under Windows, these can easily be stored in the registry. If you
want, I can let you have some "Read/save Combo-box contents" functions
(VB6+API) or a small stand-alone program to create such selections.

On Jul 2, 5:49 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 2, 8:20 am, jjj <jason31...@gmail.com> wrote:
>
> > Then tell me why turning 'on for all pages' causes firebug to fail to
> > turn on while browsing in firefox?
>
> I don't know why this does not work for you. It works for me.
>
>
>
> > Can you confirm that by turning 'on for all pages', firebug stays on
> > for every single page until you explicitly turn it off?
>
> I can confirm that Firebug will stay on for me if I select "on for all
> pages" then visit a set of completely different sites.
>
> Here is are the specifics:
> 1) Open Firefox 3.5 with Firebug 1.5a7.
> 2) Right click Firebug Icon, select On for all Web Pages.
> 3) Openwww.google.comfirebug is up
> 4) search for "foo" and click on the first result,http://en.wikipedia.org/wiki/Foo;
> Firebug is up.
> 5) typehttp://www.ibm.cominto the location bar, hit enter. Firebug

johnjbarton

unread,
Jul 4, 2009, 10:57:50 AM7/4/09
to Firebug
The option "Off for all pages, except" is already implemented. Here
is how you use it:

First, please note that you do not need to select any option to cause
"off for all pages", because Firebug is off by default. So the only
part you need to concentrate on is "except".

To create an exception to the "off for all pages" rule, do the
following:
1) open the site you want to debug
2) press the firebug status bar icon.
Firebug will open and put that site on the white list. From now on
that page will be "except".

jjb
> > 3) Openwww.google.comfirebugis up
> > 4) search for "foo" and click on the first result,http://en.wikipedia.org/wiki/Foo;
> > Firebug is up.
> > 5) typehttp://www.ibm.comintothe location bar, hit enter. Firebug

jjj

unread,
Jul 4, 2009, 3:42:24 PM7/4/09
to Firebug
Wrong. A well-designed UI should never disable the [x] metaphor
because of a poor design that has thrown the baby out with the
bathwater.

jjj

On Jul 3, 11:05 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 3, 10:22 pm, sir_brizz <bj.car...@gmail.com> wrote:
> ...>
>
> > You're missing my point completely here.
>
> And I'll keep missing the point until you break it down in ways I can
> understand. Oh wait you did:
>
>
>
> > Right click Firebug
> > Check "On for all pages"
> > Go tohttp://www.yahoo.com[Firebugpanel opens]
> > Minimize Firebug
> > Go tohttp://www.google.com[Firebugremains minimized correctly]
>
> > At this point, what I WANT to do is keep Firebug "minimized" but
> > disable it forhttp://www.google.com, so I:
>
> > Click the bug
>
> This is the UI operation for un-minimizing Firebug.
>
> > Click the [x]
>
> This is a bug: the [X] should be disabled.
>
> > Go tohttp://www.yahoo.com[Firebugpanel opens incorrectly, in my

johnjbarton

unread,
Jul 5, 2009, 11:45:56 AM7/5/09
to Firebug
I welcome your specific suggestions on how the user interface can be
clearer and more consistent. The [X] is not a metaphor, it is a
button. We need a user interaction to deactivate Firebug for a web
page. In my opinion, clicking [X] is an adequate solution. If you do
not like that solution, propose an alternative.

jjb

On Jul 4, 12:42 pm, jjj <jason31...@gmail.com> wrote:
> Wrong.  A well-designed UI should never disable the [x] metaphor
> because of a poor design that has thrown the baby out with the
> bathwater.
>
> jjj
>
> On Jul 3, 11:05 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
>
> > On Jul 3, 10:22 pm, sir_brizz <bj.car...@gmail.com> wrote:
> > ...>
>
> > > You're missing my point completely here.
>
> > And I'll keep missing the point until you break it down in ways I can
> > understand. Oh wait you did:
>
> > > Right click Firebug
> > > Check "On for all pages"
> > > Go tohttp://www.yahoo.com[Firebugpanelopens]
> > > Minimize Firebug
> > > Go tohttp://www.google.com[Firebugremainsminimized correctly]
>
> > > At this point, what I WANT to do is keep Firebug "minimized" but
> > > disable it forhttp://www.google.com, so I:
>
> > > Click the bug
>
> > This is the UI operation for un-minimizing Firebug.
>
> > > Click the [x]
>
> > This is a bug: the [X] should be disabled.
>
> > > Go tohttp://www.yahoo.com[Firebugpanelopens incorrectly, in my

alfonsoml

unread,
Jul 5, 2009, 12:10:39 PM7/5/09
to Firebug
An entry in the context menu of the firebug statusbar icon:
Disable Firebug for "xyz.com"
> > > > Go tohttp://www.yahoo.com[Firebugpanelopensincorrectly, in my

johnjbarton

unread,
Jul 5, 2009, 1:29:19 PM7/5/09
to Firebug


On Jul 5, 9:10 am, alfonsoml <aml...@gmail.com> wrote:
> An entry in the context menu of the firebug statusbar icon:
> Disable Firebug for "xyz.com"

I gather you think that a hidden menu entry with text is better than a
visible iconic button? Do others agree? Other choices?

jjb

sir_brizz

unread,
Jul 5, 2009, 1:50:26 PM7/5/09
to Firebug
I don't really mind the X, personally, it's just confusing how it
works based on how every version of Firebug prior to 1.4 has worked. X
has closed the panel. Maybe something as simple as switching the
position of close and minimize would help?

Another annoying thing is that the icons for those buttons in OSX
don't match the window style buttons at all.

Rako

unread,
Jul 6, 2009, 6:38:16 AM7/6/09
to Firebug
But that is
1.) confusing
2.) causes extra work
There should be an "off for all pages" rule, which would not allow
exceptions, thus you could switch FB off even for the site(s) you are
testing.
No exceptions would be allowed.
The rule "off for all pages, except" would be the current "off for
all pages" rule.
Thus when I add new pages, etc to my site, I could set the "off for
all pages" rule until I need FB to debug the javascript, when I would
switch to the "off for all pages except" rule, which specifies my
exception(s).
It is questionable, whether the "on for all pages" rule is legally
allowed.
My code is my intelectual property protected by national and
international copyright laws. I might even sue anyone stealing my code
for his site.
Thus FB should prevent intelectual theft, not encourage it. I read a
number of posts from people who state, that they use FB for reverse
engineering.
These request should not be complied with.
I would go even further to prevent such misdemanour: there should be a
kind of "password" protection that would allow only the owner(s) to
run FB on their site.
When entering an exception, a password should be entered (cookie?)
which would be sent to a "Firebug" module at the website. This would
be a PHP module slightly modified by the user using a small standalone
program and then stored on the server.
This standalone program would ask for the new name of the module, the
passport and for a choice of passport encryption/security routines.
FB could be activated for a site only when:
1.) the named security-module exists at the site
2.) the the password is correct, in which case an "Allow" reply would
be sent. This would depend on the selected security routine.

Of course you could argue:
1.) it is not your job to prevent theft of code:
As you provide means for this theft, the courts may not accept this
argument
2.) if someone really wants it, he can find ways to get around this
security feature.
If someone is able to do that, than he is able to develop the code for
his page himself, does not need to steal the code.
If he than puts his solution on the internet, HE is commiting a crime,
and all those, who use it to steal code.
3.) Stupid/lazy people do not program their sites themself, but use
such programs that provide code off the shelf, ignoring the fact, that
these, being jacks of all trade, mean a huge overhead for each page.
Most of these programs cost a lot of money and buying pirated code
would be cheaper.
> > > 5) typehttp://www.ibm.comintothelocation bar, hit enter. Firebug

Rako

unread,
Jul 6, 2009, 6:45:38 AM7/6/09
to Firebug
I personally do not like the "X" button, unless the reaction on
clicking it is the same very time.
Instead of the standard "X" I would use alternatives, depending on the
action following the click.
These alternatives could be at the same place and differ in colour/
background colour, or at least in the text displayed when the mouse
hovers over it.
A click could even result in the display of a select-box with possible
alternative actions.

alfonsoml

unread,
Jul 6, 2009, 6:49:40 AM7/6/09
to Firebug
Please, get back to reality.

Firebug only shows what the server has sent. If you care so much about
your intellectual property then force everyone that access your site
to sign an agreement. There's no law anywhere that would avoid showing
the source of a page, and that's basically what Firebug does.

Talking about this kind of ideas is just wasting the time of everyone
as they aren't realistic.

Let's focus on the UI of Firebug and how it can be modified to work
better.
> > > > 5) typehttp://www.ibm.comintothelocationbar, hit enter. Firebug

alfonsoml

unread,
Jul 6, 2009, 6:54:37 AM7/6/09
to Firebug
As sir_brizz says, previous versions linked the "close" button just to
the panel, not to the state of Firebug.

For me Firebug is a background task, it must be running always in
every page that I'm working on (based on domains, not on the exact
page url), and I might need to open or close the panel to view some
state, debug a function, etc.. but the panel is just the interface of
Firebug, the internal code that catches errors, keeps trace of network
resources is separate and shouldn't be linked together. If I enable
Firebug for a domain it should work automatically for every page of
that domain until I disable it, without the need to open the panel and
without disabling itself when I close the panel with the same button
that I've been doing since eons ago.

johnjbarton

unread,
Jul 6, 2009, 11:19:00 AM7/6/09
to Firebug


On Jul 6, 3:54 am, alfonsoml <aml...@gmail.com> wrote:
> On Jul 5, 7:29 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
>
> > On Jul 5, 9:10 am, alfonsoml <aml...@gmail.com> wrote:
>
> > > An entry in the context menu of the firebug statusbar icon:
> > > Disable Firebug for "xyz.com"
>
> > I gather you think that a hidden menu entry with text is better than a
> > visible iconic button?  Do others agree?  Other choices?
>
> > jjb
>
> As sir_brizz says, previous versions linked the "close" button just to
> the panel, not to the state of Firebug.

But here again you are proposing a solution where I don't see a
problem.

>
> For me Firebug is a background task, it must be running always in
> every page that I'm working on (based on domains, not on the exact
> page url), and I might need to open or close the panel to view some
> state, debug a function, etc.. but the panel is just the interface of
> Firebug, the internal code that catches errors, keeps trace of network
> resources is separate and shouldn't be linked together. If I enable
> Firebug for a domain it should work automatically for every page of
> that domain until I disable it, without the need to open the panel and
> without disabling itself when I close the panel with the same button
> that I've been doing since eons ago.

Ok there are two things I understand from this description.

First, 1.3 had a [X] that implemented minimize. So you are confused
because 1.4 uses [X] for a different purpose. I totally forgot that
1.3 had an [X] button, I thought we added it new to 1.4.

Second, I'm now in a jam because I need a two icons one for
"deactivate" (1.4 uses [X]) and one for minimize (1.4 uses [_]).

I hope you can understand why I can't just change the [X] button to
implement minimize. Then I don't have a button for deactivate and I
have two buttons that both implement minimize right next to each
other.

jjb

jjj

unread,
Jul 6, 2009, 12:12:16 PM7/6/09
to Firebug
Problem:

There is no way to monitor network activity when the firebug panel is
closed.

jjj

Nicolas Hatier

unread,
Jul 6, 2009, 12:40:21 PM7/6/09
to fir...@googlegroups.com

As written by many people before me, the [x] button deactivating Firebug is not intuitive. We are aware that a X button on an external window closes that window, and may close the application if it's the last window. But the X button on a panel usually only closes that UI element, not the service/application behind it.

Just in Firefox, there is several examples of that: If you click the X button on the History panel, Firefox continues to remember you pages history. If you have, say, the AdBlock Plus extension and close the "blockable items" panel using its X button, AdBlock Plus continues to run. There is many other examples.

Of course, the same argument could work in the other direction - If I click the X button of a Firefox tab, the tab is closed for good and the page behind it is disappeared.

My point is, the "right" (design-wise) thing to do when the X button is clicked may or may not be to disable Firebug. But, given the amount of feedback received yet, disabling Firebug is probably not the right thing to do. We saw a lot of comments telling it's not OK, and a few comments telling something along the lines of "I didn't expect that, but I can get along with it". I didn't read any comment yet telling something like "yay, I didn't understand why the 1.3 X buttn didn't disable Firebug"...

For me, the X button doesn't do what it should, but I can get along with it. I would probably prefer the minimize [_] button to be moved where the X button currently is, and the X button removed, replaced by two menu entries in the Firebug icon right-click menu: "Disable Firebug for this page", and "Disable Firebug for this domain", which would simply remove the annotations for the page or the domain.

Regards

NH

johnjbarton

unread,
Jul 6, 2009, 1:00:05 PM7/6/09
to Firebug


On Jul 6, 9:12 am, jjj <jason31...@gmail.com> wrote:
> Problem:
>
> There is no way to monitor network activity when the firebug panel is
> closed.

To monitor network activity in Firebug 1.4 while the Firebug UI is
hidden, you need to minimize Firebug. There are two ways to do that:
1) click the Firebug Status bar Icon a second time. This mechanism
means that for sites you debug a lot, this is the only button you need
to use:
First click: ON, 2nd minimize, 3rd un-minimize, 4th, minimize. Very
convenient, try it.
2) Click the minimize button on the ui upper right corner [_].

jjb

johnjbarton

unread,
Jul 6, 2009, 1:04:11 PM7/6/09
to Firebug
So this problem would be resolved if the [X] button was removed and a
new button at the same location appeared with a label like [Off] and a
tool tip saying "Deactivate Firebug for this site"?

I want some thing on the primary UI for deactivation.

jjb

Trevan Richins

unread,
Jul 6, 2009, 1:05:27 PM7/6/09
to fir...@googlegroups.com
Jjj - When it is minimized, it works fine. If you deactivate firebug, then it isn't going to monitor the network.


As for me, the X in 1.4 confused me because it functions differently than the X in 1.3. In 1.3, it minimizes. The deactivation/activation stuff was hidden away somewhere else (which I rarely used as I didn't like, so I'm personally glad it is gone). But now 1.4 has changed the X to a different function. Instead of just minimizing, it deactivates the page. This confused me when I used the "On for all pages" and for just normal debugging. I'd do the "On for all pages", go to a site that I want to look at, open firebug, look at the stuff, then hit the "X" expecting to minimize. The next page would pop open firebug. I'd minimize it again (using the "X"), and so the next page would pop open. Finally, I'd turn off the "On for all pages" and didn't use it for quite a while until I relearned the "X". Now I use the "On for all pages" quite a bit.

As for normal debugging, I'd open firebug, use it, then minimize it (again using the "X"). Refresh the page and firebug didn't record the network requests. Boy, was I not happy :)

That was when I started writing to the thread saying how I didn't like the new activation model. But after relearning the "X", I'm pretty happy with it. Especially since attempting to write an extension and discovered that it is not as simple as it seemed :)

So, I think the biggest problem is that people from 1.3 are used to the "X" minimizing the panel and not deactivating it. By changing its functionality in 1.4, 1.3 users are now seeing firebug popup when unexpected (if they have "On for all pages") or not recording their network requests.

Again, here's some scenarios that I think are causing the most grief:

1 - Select "On For all Pages"
2 - Firebug opens
3 - Minimize (by using the "X" because that is how you did it in 1.3)
4 - Go to a new page
5 - Firebug opens without being clicked on

1 - Go to a page and open firebug
2 - Do some debugging
3 - Minimize (by using the "X" because that is how you did it in 1.3)
4 - Do some work on the page
5 - Reload the page to check some ajax requests or console lines
6 - Firebug didn't record the ajax requests or the console lines

1 - Go to a page and open firebug
2 - Minimize (this time with the minimize button because you remembered. Yeah!)
2 - Go to another page and open firebug
3 - Minimize (by using the "X" because you forgot)
4 - Go back to first page
5 - Firebug opens unexpectedly (because you had minimized it)

In all scenarios, the mistaken identity of the "X" causes the issues.

What should be done? It took me a few days to figure out that the "X" in 1.4 is different than 1.3 and now I have no problem with it. But there was no documentation to tell me what was happening. When I complained on the emailing list, no one explained (mostly my fault because I wasn't explaining myself correctly :) ). Some ideas, though, to fix it without requiring a relearn or to help relearning it are:

1 - When you click the "X", an alert saying "Do you really want to deactivate Firebug?" with a box to check for "Never alert me again".
2 - Do not have an "X". Leave the space empty and put a new icon that deactivates next to it.
3 - Swap the "X" and the "_" icons.
4 - Change the "X" to be minimize, and change the "_" icon to something else that does deactivation.


As someone had already mentioned, AdBlock's Blockable Items panel has an "X" that doesn't deactivate AdBlock. As well as HttpFox.

Just my 2 cents,

Trevan

johnjbarton

unread,
Jul 6, 2009, 1:13:49 PM7/6/09
to Firebug


On Jul 6, 10:05 am, Trevan Richins <TRich...@omniture.com> wrote:
...
> So, I think the biggest problem is that people from 1.3 are used to the "X" minimizing the panel and not deactivating it.  By changing its functionality in 1.4, 1.3 users are now seeing firebug popup when unexpected (if they have "On for all pages") or not recording their network requests.

Yes, I can see this for sure. I did not remember that 1.3 had an [X],
it was my mistake to re-define it.

>
> Again, here's some scenarios that I think are causing the most grief:
>
> 1 - Select "On For all Pages"
> 2 - Firebug opens
> 3 - Minimize (by using the "X" because that is how you did it in 1.3)
> 4 - Go to a new page
> 5 - Firebug opens without being clicked on

Yes, I hope I do not forget to fix this problem.

>
> 1 - Go to a page and open firebug
> 2 - Do some debugging
> 3 - Minimize (by using the "X" because that is how you did it in 1.3)
> 4 - Do some work on the page
> 5 - Reload the page to check some ajax requests or console lines
> 6 - Firebug didn't record the ajax requests or the console lines

Ok, I'll get rid of the [x] in 1.4


>
> 1 - Go to a page and open firebug
> 2 - Minimize (this time with the minimize button because you remembered.  Yeah!)
> 2 - Go to another page and open firebug
> 3 - Minimize (by using the "X" because you forgot)
> 4 - Go back to first page
> 5 - Firebug opens unexpectedly (because you had minimized it)

I suggest trying the Firebug Status Bar icon, I like it a lot.

>
> In all scenarios, the mistaken identity of the "X" causes the issues.
>
> What should be done?  It took me a few days to figure out that the "X" in 1.4 is different than 1.3 and now I have no problem with it.  But there was no documentation to tell me what was happening.  When I complained on the emailing list, no one explained (mostly my fault because I wasn't explaining myself correctly :) ).  Some ideas, though, to fix it without requiring a relearn or to help relearning it are:
>
> 1 - When you click the "X", an alert saying "Do you really want to deactivate Firebug?" with a box to check for "Never alert me again".
> 2 - Do not have an "X".  Leave the space empty and put a new icon that deactivates next to it.

I am leaning towards: replace [X] icon with [Off] button.

> 3 - Swap the "X" and the "_" icons.
> 4 - Change the "X" to be minimize, and change the "_" icon to something else that does deactivation.
>
> As someone had already mentioned, AdBlock's Blockable Items panel has an "X" that doesn't deactivate AdBlock.  As well as HttpFox.
>
> Just my 2 cents,

Well said, and cheap too ;-)
jjb

Rako

unread,
Jul 6, 2009, 1:39:58 PM7/6/09
to Firebug
Alfonsoml,
you seem to ignore the fact, that the javascript code in separate
modules is not displayed when showing the page.
It is accessable only by using firebug or a similar product.
A lot of people protect their intellectual property by obfuscating
their code.
There were demands, that Firebug should help them in reverse
engineering. This reverse engineering is done probably to steal
someone's code.
I must assume, that you object to my proposal, because you may want to
use code developed by someone else.

My proposal is simple and realistic. I am long enough in this
profession (since 1962) to be able to judge, what can be done with
reasonable effort.

The security of proprietary code IS a legally binding obligation for
such programs. Without that FB could even be classified as spyware and
its authors could be prosecuted.
This is what MUST be avoided. I love Firebug (although I have not used
it for the last few month) and I would not like its developers get
into trouble because some thiefs or saboteours.
Because knowing how the hidden javascript operates, you could
circumwent the safety measures programmed there. .

I suppose you wrote your post, because you are not experienced enough
and not because you plan some mischief.

As for a a sign-on and accepting an agreement, I have that on my site.
Not only because of the design and javascript code, but also because
of its contents:
there are a number of historical documents there, which are first
published at my site and have to be protected.

Nicolas Hatier

unread,
Jul 6, 2009, 1:47:57 PM7/6/09
to fir...@googlegroups.com
I would think so, but would probably better if the [Off] button would be at the left of all buttons, and the [_] button would be where the [X] button currently is:

[Off] [some space] [8] [_]
or (to keep the normal order of buttons, maybe)
[Off] [some space] [_] [8]

Of course, this is just my opinion, I'm don't have an argument for or against a particular button order, except that the button hiding the Firebug UI (minimize) should be the rightmost.

Regards
NH

Trevan Richins

unread,
Jul 6, 2009, 1:53:33 PM7/6/09
to fir...@googlegroups.com
If you develop for the web, expect your stuff to be viewable. People have for years attempted to prevent downloading of images, movies, source code. Images have been "protected" by disabling right-click and using background-image css (that I know of). Movies have attempted to do it by not sending the entire film at once, but in pieces. And source code by attempting to prevent right-click and view source. None of these work. It doesn't take a genius to get around them.

If someone wants to see javascript code, they can (in Firefox pre-3.5 and all other browsers):

View source
Find the javascript link
Copy and paste into URL
Your code has been seen

In Firefox 3.5, they can just click on the URL in the source code.

Of course, IE8, Safari, and Chrome all come with a debugger built-in that let you see the source code of all requests.

Plus, you proprietary source code is cached on the persons machine so they can pull it from there.


So, your suggestion is pretty much useless. Far too many ways to get to the code without needing Firebug and that are easier or just as easy. If you want to protect your intellectual property, then don't use javascript.

Trevan


-----Original Message-----
From: fir...@googlegroups.com [mailto:fir...@googlegroups.com] On Behalf Of Rako
Sent: Monday, July 06, 2009 11:40 AM
To: Firebug
Subject: Re: New Activation Model


Trevan Richins

unread,
Jul 6, 2009, 1:56:50 PM7/6/09
to fir...@googlegroups.com
> The security of proprietary code IS a legally binding obligation for
> such programs. Without that FB could even be classified as spyware and
> its authors could be prosecuted.
> This is what MUST be avoided. I love Firebug (although I have not used
> it for the last few month) and I would not like its developers get
> into trouble because some thiefs or saboteours.
> Because knowing how the hidden javascript operates, you could
> circumwent the safety measures programmed there. .

And one more thing. You should NEVER use javascript as the only security measure. I hope you know that already, though, since you've been in this profession since 1962.

alfonsoml

unread,
Jul 6, 2009, 4:15:30 PM7/6/09
to Firebug


On Jul 6, 5:19 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:

> First, 1.3 had a [X] that implemented minimize. So you are confused
> because 1.4 uses [X] for a different purpose. I totally forgot that
> 1.3 had an [X] button, I thought we added it new to 1.4.

Trust me, you didn't add that button at that time:
http://web.archive.org/web/20061203051037/http://www.getfirebug.com/index.html
You might have been changing the way that it works along the way, but
the [X] button has been there from the very start and there are too
many people out there that have always used it the same way before 1.4
arrived.

If you want a button to deactivate it in the primary UI, then go ahead
and add it, but don't change the behavior of existing buttons in such
an important way

Rako

unread,
Jul 7, 2009, 2:32:31 AM7/7/09
to Firebug
I agree with all you say, but what annoys me, are the requests for new
features in FB to enable reverse engineering.
Obfuscating my javascript code will make it more difficult for people
to steal it.
If you look at the source-code of this page and than click on the link
to the javascript library, have a look at the "unintelligible" string
of code, you will probably say: it is too much effort to find out how
it works.
If then Firebug has capabilities to nullify this, FB goes one step too
far. But a security-hole in a previous version does not mean that it
should not be plugged.
If the code is complex enough to need protection, an outsider will
have difficulties to understand it. He may look at the code,
understand how certain functions work, but not the full interaction
and dependencies of all the functions, especially if they are spread
over a number of modules.
I have no objection to someone looking at my code to learn from it,
but if I would find someone selling my code as his own, I would crack
down on him.

There is always a logistical problem, especially if you have
relatively little space on the server and a lot of data:
Do I have a private site for testing with fully legible and annotated
code and obfuscated one on the public site, or do I have just one site
and risk someone stealing my code.

As you say, if someone knows his way how to get to the code, he will
get it, but that is no argument against building some easily
implementable measure into Firebug, that would try to ensure that only
authorised persons can use FB on that site.
Perhaps even looking at the source-code may not be quite legal. Some
clever lawyer could make a case for having this banned.

With this in the pocket, one could force the other browser developers
to implement such things too.

alfonsoml

unread,
Jul 7, 2009, 6:34:09 AM7/7/09
to Firebug


On Jul 7, 8:32 am, Rako <mscam...@rakovszky.eu> wrote:
> I agree with all you say, but what annoys me, are the requests for new
> features in FB to enable reverse engineering.

Then place your rants in those threads.
This is already too heated, please, don't mix unrelated things.

sir_brizz

unread,
Jul 7, 2009, 10:34:34 AM7/7/09
to Firebug
I agree with this. The button that minimizes Firebug should be the
upper right-most icon.

Rako

unread,
Jul 7, 2009, 2:33:18 PM7/7/09
to Firebug
I do not rant.
I simply explain why is this extension/modification to/of the
activation needed.
Perhaps my reasoning offends you (are you one of the reverse-
engineers?), but it is not going to change my reasoning.

Rob Campbell

unread,
Jul 8, 2009, 12:47:05 PM7/8/09
to Firebug
Rako, further obfuscation of JS code will never be a feature of
Firebug. Most minimized JS is already quite obfuscated and, if
anything, we'll produce a mechanism to display it more legibly, either
by extension or with a feature.

As for the Off vs [X] button, I really feel this was a bit of a wasted
effort and a discussion that blew the issue out of proportion. Now
we've implemented this change to appease a noisy few. Most users will
learn that the [X] button means "Close / Off" after they've used it.
It behaves similarly to how you'd expect a close button to work in any
other area of Firefox or the OS. I, for one, will be glad to see the
"Off" label go away as soon as possible.

sir_brizz

unread,
Jul 8, 2009, 2:06:58 PM7/8/09
to Firebug
I like how you just cast off our disappointment with the way this
feature was implemented. o_O I took issue with the new activation
model months ago, you could have read the signs back then when people
agreed with me.

I'll be happy if the button order is changed so that the minimize
button is in the corner. As someone else pointed out here or another
thread, this is a tool for developers. The likelihood that someone
developing on a site is going to be enabling and disabling firebug a
million miles a minute is minute. The more likely scenario is that
they will want it on for a domain and then forget about it (minimize
it) until something happens that causes them to need to interact with
it.

Not only was this a break from the earlier functionality of Firebug,
it's also moving functionality that is not always wanted or needed
into a prime location for accidental clicking.

Anyway, the firebug team could easily avoid this by either allowing
extension hooks into the location/format/form of those three buttons,
or simply having an option that moves the "close and disable" button
somewhere else or removes it entirely.

johnjbarton

unread,
Jul 8, 2009, 4:04:43 PM7/8/09
to Firebug
I am interested why you don't think the status bar icon is a good
solution to minimize/unminimze.

jjb

sir_brizz

unread,
Jul 8, 2009, 6:33:32 PM7/8/09
to Firebug
You mean the bug? I think the bug is fine, but I don't just always use
it. I have half a dozen Firefox extensions that all occasionally open
panels inside Firefox that have a close button in the upper right
corner, so I have become accustomed to clicking the button in the
upper right corner of the panel to move it out of my way (not disable
the extension completely).

Personally, I don't mind having a button that closes and disables
Firebug for the current domain, I just think the icon used for it, the
position it was placed in and the implications of that were not fully
thought through before that decision was made. I'm still not sold on
the activation model as a whole, but getting the close button out of
the upper right corner of Firebug and putting the minimize button
there would go a long way toward me not caring about getting used to
it anymore.

Brade

unread,
Jul 9, 2009, 8:15:23 AM7/9/09
to Firebug
It seems like the latest firebug 1.4 addresses some of the major
annoyances I had. It looks like domain whitelisting happens (although
it is implicit now), in my case for localhost. It also seems like when
I switch pages, the panel stays put (or stays hidden) for the tab I'm
on. If so, these are steps in the right direction. I'm less concerned
about position of the X button and more concerned with domain
whitelisting and panel sanity.

Rako

unread,
Jul 9, 2009, 2:56:30 PM7/9/09
to Firebug
I agree with you, that there is no need for Firebug to "obfuscate" JS
code.
What I object, is the request to implement features that would
counteract the obfuscation created by the owner of the site.
What I suggested, is a method, through which owners of web-sites could
allow/forbid the use of FB by strangers to "debug" their code.
I think FB should not try to display obfuscated code more legibly.
This would tantamount to try to decifer encripted data.
I have no objection to stand-alone programs to make obfuscated code
more legible, but as a feature of Firebug it would be criminal.
Would you like to have programs around that spy-out your passwords,
decript your private emails? I would not.
Please do not turn Firebug into Spyware.

Luke Maurer

unread,
Jul 9, 2009, 4:10:11 PM7/9/09
to Firebug
You must be using a pretty wimpy obfuscator if a mere code formatter
will undo it. If your IP is the big issue here, won't you be using
something that does more than get rid of whitespace? Like renaming
local and private variables to nonsense? That's not something that
Firebug *could* undo, with or without DRM-style permission bits.

- Luke

sir_brizz

unread,
Jul 9, 2009, 5:29:12 PM7/9/09
to Firebug
This whole line of argument is just stupid. The web is built on open
standards. If you don't want your site to be built on the web, then
use flash or something.

Bob Hassinger

unread,
Jul 9, 2009, 5:43:41 PM7/9/09
to fir...@googlegroups.com, Bob Hassinger
This famous quote comes to mind:

"God grant me the serenity
to accept the things I cannot change;
courage to change the things I can;
and wisdom to know the difference."

Rako, you are chasing a hopeless result. Even if you manage to get
Firebug to be less helpful, there will be another tool, and another,
and another. Firebug is only one of many tools even now. You can not
possibly plug up the holes as fast as they are developed.

Security through obscurity can only give an allusion of protection
that diverts ones efforts that should go into measures that can really
ensure protection.

Every end user has full and unlimited access to whatever you send to
their computer (including everything in referenced files like external
Javascript and CSS files), for as long as they want it. If a browser
can understand the code then a human can. Fundamentally there is
little difference between intentionally obfuscated code and just plain
old poorly written code. An interested person goes through the same
process to sort it out. In essence once you send it to them you have
given up any possible trade secret protection and your only real
option is copyright (or maybe patent). And still, enforcement of
those protections is only really feasible in major situations with a
lot of money involved.

By its nature Javascript is just not the tool for you when you need to
hide your logic or coding, or provide security for your site/data.
You have to do it so that users never have access to it in any form -
say in host side processing for example.

Consider the balance for this one: On one side we are looking at
widely beneficial capabilities many people will find very helpful. On
the other side you want those benefits denied to them so you can have
the illusion of restricting access to what can not really be
protected. I think the choice there is easy - one person's illusion
of gain, against the whole user communities's real gain. I suspect
that is a pretty easy call.

Kara Rawson

unread,
Jul 9, 2009, 6:08:18 PM7/9/09
to fir...@googlegroups.com
ummm i thought FB was suppose to do the opposite of obfuscation, like
make code easier and faster to understand and debug. btw thats a great
quote, every dev should know that by heart. M$ uses that secuirty
paradignm and look where that got em, the most widely used, abused, and
hacked piece of software known to man. Restricting access is the only
way to keep things secure. Nothing is private that is on the
web/internets. The simple fact of it being on the internet implicity
makes it public. Obfuscating code only protects you from crackers who
dont know what they are doing, and the chances of thsoe peopel crippling
your system are pretty nile. generally all IP or protected logic gets
coded as RPC services and your web app / site access these using some
type of RESTful interface via AJAX/COMET. Then your code is actually
protected by something, a firewall most likely.

kara

Rako

unread,
Jul 10, 2009, 5:18:31 AM7/10/09
to Firebug
You must make a difference between the owner of a site, who wants to
develop his/her own code, and strangers.
Firebug should cater only for those, who want to develop their own
code.
The will do this in its original form, which is/should be easily
readable, so that the developer sees what he intends to do.
Once the development is complete, this code can be condensed by stand-
alone programs, so that it downloads and is interpreted much faster.
It is this code what I call obfuscated: no comments, machine-generated
short names instead of intelligible description.
The owner still has the original code for further development.
It is up to the owner to let everyone see the full code, or just the
obfuscated one.

Firebug should not try to make such code more legible, intelligible,
otherwise it turns itself into spyware.
The argument, that if someone wants to decode the obfuscated code and
steal it, he can find enough other tools to do it, is no justification
for implementing something into FB to do it.
Also, no FB-add-on should be allowed to do it. At least none that is
official or has the blessing of the FB-crew.

FB has more important functions that need to be implemented or
improved, like a positive activation-list (Disabled for all except:)
When I am developing my own code, I want to have FB active for my site
only - which may be linked to/from other sites. I have no time to test
the code of others, especially, if the throw up errors.
I would like to be able to restrict FB monitoring even to specified
pages within my site, as this would save a lot of time by pages
further down the hierarchy.

Rako

unread,
Jul 10, 2009, 5:32:04 AM7/10/09
to Firebug
You are mistaken in your statment, that if a browser can understand
you code, than a human can do too.
It is false in both ways.
Small spelling-differences can make the code "unintelligible" for the
browser, but intelligible for humans.

Condensed (obfuscated) code can be understood by the browser, but not
necessarily by human beings.
Simple code may be, but code consisting of many thausends of
statements with names like "a5D", "A5d" will give the would be reader
such a headache, the he gives up and develops his own code.

In the main thing I agree with you, you cannot protect your code
absolutely. If someone steals it for private use, you have hardly any
chance to get to know of it.
Only if someone tries to market your code under his own name, that you
may take steps. In such cases you may even succeed.

As for having a look at non-obfuscated code for learning causes, I
find that not only OK, but even a good thing.
Often your code refuses to work, while the same thing works elsewhere.
By looking at the working code, you can identify your error without
stealing the code of other's.
But please use only "open" (= not obfuscated/compressed) code. There
is enough of that.

Player

unread,
Jul 10, 2009, 7:57:51 AM7/10/09
to Firebug
Hi,

Can i use something like "white list", to add domains, where Firebug
will always enabled, without clicking to the FB icon or open FB window/
pane?

johnjbarton

unread,
Jul 10, 2009, 10:48:05 AM7/10/09
to Firebug
In 1.4 you add domains to the white list by opening Firebug on the
page.
jjb

Highway of Life

unread,
Jul 10, 2009, 2:55:35 PM7/10/09
to Firebug
John,

I wanted to thank you for changing (x) to an "off" button, it is much
more intuitive and clearer to use. Between the changes made to the
activation model in 1.5a7 and the changing of the off button, I have
no complaints about Firebug.

Thanks!
- Highway of Life
Software Engineer
Reply all
Reply to author
Forward
0 new messages