New activation model in Firebug 1.4

[John J Barton]

Firebug 1.4a16 is available from http://getfirebug.com/releases/firebug/1.4X.
We are getting close to beta.

One of the issues we need feedback on is the new activation model. Of
special importance are ideas for how to support use models that suffer
in the new scheme without adding options to the UI.

jjb

[niver]

Personally I was liking the per-site activation. Developpers are
likely to use Firebug with a small subset of sites, and to almost
always need Firebug for those sites - and not for the others.

Firebug should be disabled by default, and be enabled for specific
sites only. I don't think the previous "enabled everywhere but on some
sites" possibility was often used. But I may be wrong.

N.

On Apr 2, 1:27 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Firebug 1.4a16 is available fromhttp://getfirebug.com/releases/firebug/1.4X.

[Trevan Richins]

I have mixed reviews. I was a person that used the "enabled everywhere but on some sites" setting because I liked to look at how other sites worked every now and then. I think there are actually two uses for firebug:

Looking at CSS and HTML
Using console.log and ajax listening

This new model works great for the CSS and HTML usage. You can turn on firebug on the site you are looking at, check out the css and html, close firebug and be done.

But for console.log and ajax listening (especially at page load), it doesn't really work. You have to make sure firebug is open before the page is loaded if you want to see any output of the console.log and watch any ajax calls. And since firebug closes itself on every new page, this makes watching stuff on page load very frustrating.

Personally, if I have firebug open in a tab, I expect it to stay open in that tab until I close it (and for it to be listening for ajax requests and console.log calls on that tab. I don't care if I'm switching domains or staying in the same domain, if I opened up, stay open. Since I'm usually debugging more than one page, this new model is becoming very frustrating. I setup the environment, I go through the steps to get the form to submit, I submit expecting to check ajax requests and console.log calls on the next page and firebug closes. Completely destroying the possibility to debug. I've started changing console.log to something else and catching ajax requests in another way just so I can work.

Another frustrating aspect is that one workaround this issue is to make sure firebug has already been opened on each of the pages. This makes firebug stay open when you switch pages. But when I'm done debugging, I close it and assume that it should stay closed. But firebug only closes it for the page I'm currently on. If I go to one of the other pages, firebug reopens unexpectedly. So I close it. Another page reopens it, I close it. And it continues (I've usually opened it on 10+ pages in the course of debugging). And now that I've closed it on all those pages, when I want to debug them (for another issue), I've got to remember to reopen it on each of those pages (and I only remember after being reminded painfully after firebug closes the first couple of times on me).

[Fin6]

I like to to keep the load on my browser in the daily use at a
minimum.
So Firebug should be always off by default (and visualized to the user
by a grey roach).
When I activate it to check a site I normally deactivate it
afterwards. No need for site rules IMO.

With always off as default there should be only one option that
affects this:
If I forget to deactivate Firebug I would expect it to start
deactivated again. Good in most cases but this may be unwanted in
other cases so there should be an option to keep an activated Firebug
between sessions (browser restarts).

[littlewoodEd]

This is pretty bad.
- I open my site for the first time and firebug is disabled. I enable
script and the console (which takes too many clicks, but that's a nit)
- I detach the firebug window
- I reload. The detached firebug window goes blank, the browser
reloads my page, but firebug is disabled. So I click on the bug and a
new fb window opens in the browser, but all the tabs from the detached
window disappear and show up on the attached window. Clicking on these
tabs opens content in the detached window. I closed the detached
window, but can't close the attached window.

If I close the detached window before reloading the page, the page
reloads, and fb window stays closed but the even though the fb is
enabled, code on the page doesn't know that and dojo shows its own
html console. When I open the fb window, the console is empty - seems
nothing went there while the window was closed.

I can't believe this is working as anyone intended.
--ed

On Apr 2, 12:27 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Firebug 1.4a16 is available fromhttp://getfirebug.com/releases/firebug/1.4X.

[johnjbarton]

On Apr 3, 5:32 am, littlewoodEd <eschie...@gmail.com> wrote:
> This is pretty bad.

As it will turn out "this" means "the open in new window code for
1.4a16". (Not the activation model)

> - I open my site for the first time and firebug is disabled.  I enable
> script and the console (which takes too many clicks, but that's a nit)
> - I detach the firebug window

Ok, right here all bets are off. We have only minimal testing of open
in new window, so any problem you have is just a bug. Please open a
issue and we can fix it.

jjb

[johnjbarton]

Someone beat you to it:
http://code.google.com/p/fbug/issues/detail?id=1631

jjb

[Landon]

So you are saying that the recommended way for people to debug ajax
calls... is extremely untested and probably doesn't work. Great.

The entire reason I use firebug is I need to see things as they happen
between going to different pages. I can see the point behind the new
activation model but the implementation is horrible at the moment. I
personally think that a good mix of the way it used to work and the
new activation method is what Trevan described above where if I open
Firebug on a tab it should stay open on that tab until I either close
firebug, or close the tab.

Landon

[johnjbarton]

On Apr 3, 9:20 am, Landon <L4nd0n...@gmail.com> wrote:
> So you are saying that the recommended way for people to debug ajax
> calls... is extremely untested and probably doesn't work. Great.

I did not say the recommended way is untested. I said the open in new
window is untested. And I said that if you want to monitor pages on
tabs you can't see, open in new window.

The only thing reported as a bug against new window is reloading the
page, which you can't do if you can't see the tab anyway.

>
> The entire reason I use firebug is I need to see things as they happen
> between going to different pages. I can see the point behind the new
> activation model but the implementation is horrible at the moment. I

Ouch that's a bit harsh ;-) Really we only have on bug report it's
not that bad.

> personally think that a good mix of the way it used to work and the
> new activation method is what Trevan described above where if I open
> Firebug on a tab it should stay open on that tab until I either close
> firebug, or close the tab.

I have been thinking about Trevan's suggestion. Another one by Steve
Souders is also possible: no per site setting at all. If you open
Firebug it is on for all tabs and pages. If you close it, it is off
for all tabs and pages. EOF.


>
> Landon

[dm]

Hi all,

So far for me the new activation seems fine for my limited needs, but
reading people's responses I wondered whether it might be an option to
add to the context menu when right-clicking a link to open the page
with Firebug enabled. This would prevent one opening a new link,
opening firebug and then having to reload.

Possible?

d

[Trevan Richins]

> I have been thinking about Trevan's suggestion. Another one by Steve
> Souders is also possible: no per site setting at all. If you open
> Firebug it is on for all tabs and pages. If you close it, it is off
> for all tabs and pages. EOF.

The one issue I would have with having it open on all tabs is that I don't want XHR requests and JS errors jumbled together. If Firebug can differentiate between which page I'm current looking at and only show the XHR requests and JS errors for that page, then I'm fine with firebug being open across all tabs/pages.

Trevan

[Trevan Richins]

This wouldn't work for me because a lot of the links that I click on are not actual <a> tags, but <div> with onclick listeners. And right-click open in new tab doesn't work with those, so I don't think firebug would be able to work with them either.

[johnjbarton]

On Apr 3, 10:11 am, Trevan Richins <TRich...@omniture.com> wrote:
...

> The one issue I would have with having it open on all tabs is that I don't want XHR requests and JS errors jumbled together.  If Firebug can differentiate between which page I'm current looking at and only show the XHR requests and JS errors for that page, then I'm fine with firebug being open across all tabs/pages.

The XHR/errors handling is independent of the activation. So if we had
global on/off, it would just like you manually when to every page and
turned Firebug on. So XHR would be in the right page and most of the
errors would be in the right page. Sometime errors would be in the
wrong window, just like today.

jjb

[Landon Abney]

I would prefer to enable on a per tab basis, but a global on/off would
work as well. If the global route is taken would that be across all
firefox windows or just a single window? I often have the site that I am
working on open in one window and then use a separate window for reference.

Landon

[johnjbarton]

We have at least four options:
as is
global to Firefox
global to XUL window
always on tab
They all have problems, of different sorts.


jjb

[Maciej Jaros]

johnjbarton wrote:
> We have at least four options:
> as is
> global to Firefox
> global to XUL window
> always on tab
> They all have problems, of different sorts.
>

Use all of them? I think most of the users wouldn't mind if there would
be some default behaviour as long as they could use something different
(even if set with about:config). So maybe all could be implemented if
that's not too much work?

Regards, Nux.

[Trevan Richins]

There could be a fifth option, where it is domain specific. So if you open it on test.com/index.html, it will stay open at test.com/test.html, www.test.com/index.html, and dev.test.com/test.html. I'd prefer the tab option or the XUL window, but if the domain specific is easier, I'd be ok with it.

-----Original Message-----
From: fir...@googlegroups.com [mailto:fir...@googlegroups.com] On Behalf Of johnjbarton
Sent: Friday, April 03, 2009 12:33 PM
To: Firebug
Subject: Re: New activation model in Firebug 1.4

[mcollins]

I like the per-tab idea, but I realize that there may be times when I
will want Firebug active for multiple pages, maybe we can't have all
of them, but would more than one be a possibility?

I am thinking something like, per-tab for when firebug is docked at
the bottom, but if you pop it open in a new window, it is global to
that XUL window? In a way this makes sense to me because you are no
longer attaching firebug to one tab.

I think in 1.3 you can have as many separate firebug windows as you
have tabs open, but for people that use firebug popped open in a
separate window, would it be too unwieldy for them to use separate
browser windows if they are debugging 2 different sites?

[Nicholas Orr]

On Apr 4, 4:32 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> We have at least four options:
>   as is
>   global to Firefox
>   global to XUL window
>   always on tab
> They all have problems, of different sorts.

I'd like it global to FireFox.

I use a separate Firefox with all my dev add-ons active in it, via
portable Firefox.
Then for reference I use the system Firefox (which is zippy due to
lack of add-ons).

This way I'd actually be able to use FireBug in its own window on my
2nd screen.
Then no matter what I'm doing in the browser I can shift my eyes to
the FireBug window
to find out what I want to know about the current page.

:)

[noirsoldats]

I don't know what this new 'Activation model' is all about, but 1.4a17
is broken completely. I use firebug for a wide array of things, not
least of which is AJAX monitoring and sometimes HTML/CSS tweaking. But
this new version 1.4x is completely useless.. To the point where even
getting the HTML/CSS tweaking to work on a page is a pain in the ass.
Trying to view AJAX requests is just a nightmare.

Why was this 'change' implemented? What was it expected to address?
Can we not go back to per-site activation? Right now I have FireBug
turned on and (I assume) it's chewing away at every site my browser
loads and that is NOT acceptable.. GMail just HAS to be turned off,
and there are so many other sites that I just don't give a ****
about.. So again I ask WHY was this change implemented? Remember,
don't fix what is not broken.

But, I may also just not realize how this new version of Firebug
works, maybe you have to jump through hoops a different way to make
the new firebug work? If so could you clue me in to how it's supposed
to work now to do the common tasks it's used for before I (and
apparently some others of us) blow our brains out trying to debug
AJAX?

If I can get Firebug usable for what I need to use it for in the line
of work then I'll be happy no matter what this 'activation model' is,
but currently I'm back to doing things the hard way because firebug
just plain doesn't work. ( http://dev.codemeu.com/sandbox/files/firebug_screen1.png
)

On Apr 2, 12:27 am, John J Barton <johnjbar...@johnjbarton.com> wrote:

> Firebug 1.4a16 is available fromhttp://getfirebug.com/releases/firebug/1.4X.

[Landon Abney]

Global to firefox would cause issues with my usage as I would then
have a firebug window open on every firefox window. It sounds like
global to the XUL window would work just as well as global to firefox
for you, and is an acceptable compromise between global to all
instances of firefox windows, and active on a single tab

[aaditya sood]

I second this. I'm used to have firebug open in the tabbed interface
at the bottom of my screen to keep an eye on things. Having to re-open
it after every GET/POST is frustrating. It would be extremely helpful
to have an option to keep it persistent between page refreshes.

Since I run a special firefox profile for development I really don't
have much of an opinion about firebug gobal vs per-tab vs per site.

regards

[johnjbarton]

Based on your screen shot, your problems are with open in new window.
For the activation evaluation, please use Firebug within the browser
and use Firefox 3.0 (not 3.1b3). We're making progress on both open
in new window and FF3.1 == FF3.5 but they don't work yet.

jjb

On Apr 7, 4:55 am, noirsoldats <noirsold...@gmail.com> wrote:
> I don't know what this new 'Activation model' is all about, but 1.4a17
> is broken completely.  I use firebug for a wide array of things, not
> least of which is AJAX monitoring and sometimes HTML/CSS tweaking. But
> this new version 1.4x is completely useless..  To the point where even
> getting the HTML/CSS tweaking to work on a page is a pain in the ass.
> Trying to view AJAX requests is just a nightmare.
>
> Why was this 'change' implemented? What was it expected to address?
> Can we not go back to per-site activation? Right now I have FireBug
> turned on and (I assume) it's chewing away at every site my browser
> loads and that is NOT acceptable.. GMail just HAS to be turned off,
> and there are so many other sites that I just don't give a ****
> about.. So again I ask WHY was this change implemented? Remember,
> don't fix what is not broken.
>
> But, I may also just not realize how this new version of Firebug
> works, maybe you have to jump through hoops a different way to make
> the new firebug work? If so could you clue me in to how it's supposed
> to work now to do the common tasks it's used for before I (and
> apparently some others of us) blow our brains out trying to debug
> AJAX?
>
> If I can get Firebug usable for what I need to use it for in the line
> of work then I'll be happy no matter what this 'activation model' is,
> but currently I'm back to doing things the hard way because firebug

> just plain doesn't work. (http://dev.codemeu.com/sandbox/files/firebug_screen1.png

[Christoph Dorn]

I can see valid reasons for all proposed activation models and valid
issues/dislikes/conflicts with each specific one depending on your use
case.

Has it ever been discussed to allow them all? We can pick one default
one which is most "typical" but then allow the user to change it. We
could add a "debug profile" feature where you can specify different
debug profiles and for each profile you can specify how you want
things activated. Profiles could be browser window specific and you
could easily switch between them.

As firebug evolves there will be additional reasons for each use case.
Especially if there are new firebug extensions that need activation in
a specific way to function properly.

If we introduce the concept of debug profiles we could also add the
ability to specify custom request headers for each profile. That way
we can tell our server code to do something different if we are
accessing anything for debug purposes. By providing the basic tools to
allow systems to recognize specific developers and respond accordingly
we can open up the door to a whole new set of possible firebug
extensions.

[johnjbarton]

We are pretty sure that extensions will be able to plug in to the per-
panel enable/disable feature in 1.4. The reverse, where an extension
controls the activation of pages should also be possible, both at a
low level by changes to page annotations and at the Firebug level by
responding to Firebug events. We have less confidence about this since
no extension has tried it. But yes, in general we want to support
extensions that implement different activation models (once we get the
default to work.....)

jjb

On Apr 13, 2:59 pm, Christoph Dorn <christ...@christophdorn.com>
wrote:

[littlewoodEd]

I've started using 1.4 daily now, and it's so much faster. Once my
mouse hand starts remembering where the buttons and menus have moved
to, it's going to be more useable as well. Excellent work. I have
run into an issue with the new activation model, at least I think
that's my issue.

At work, I have 2 monitors and gobs of screen real estate , so I
didn't notice, but last night at home, with my laptop only, I ran into
trouble. Once I activated fb for a site, anytime the browser opened
the site, the fb window opened, making it difficult to exercise the
site as a user. It became annoying when I'd enter the site, fb opens
and pull the browser on top, click on a link that took me somewhere
else, go back, fb pops itself to the top.

Is this the expected behavior, or a bug? Do I need to disable fb every
time I want to simply test the site

I had opened fb in a detached window, and couldn't get it to re-
attach. The ^, v, and x buttons do nothing. I can only close fb using
the window's close button in the title bar.



I've also discovered that I can only enter watch expressions if I
click in the New watch expression box before any breakpoints get hit.
I don't have to enter anything, I just need to, for a better work
'activate' it. After that, I can use it later in my debugging. if I
don't do this, it doesn't accept input.
--ed

[johnjbarton]

On Apr 23, 5:36 am, littlewoodEd <eschie...@gmail.com> wrote:
> I've started using 1.4 daily now, and it's so much faster.  Once my
> mouse hand starts remembering where the buttons and menus have moved
> to, it's going to be more useable as well.  Excellent work.  I have
> run into an issue with the new activation model, at least I think
> that's my issue.
>
> At work, I have 2 monitors and gobs of screen real estate , so I
> didn't notice, but last night at home, with my laptop only, I ran into
> trouble.  Once I activated fb for a site, anytime the browser opened
> the site, the fb window opened, making it difficult to exercise the
> site as a user.  It became annoying when I'd enter the site, fb opens
> and pull the browser on top, click on a link that took me somewhere
> else, go back, fb pops itself to the top.
>
> Is this the expected behavior, or a bug? Do I need to disable fb every
> time I want to simply test the site

How it is supposed to work: once you close Firebug on a URL, it does
not come up next time. If so, its a bug. We have a test for the
simple case so maybe you are using a different sequence?

>
> I had opened fb in a detached window, and couldn't get it to re-
> attach. The ^, v, and x buttons do nothing.  I can only close fb using
> the window's close button in the title bar.

Yes, reattach is broken. For now we've solved the problem by making
the buttons invisible for a21.

>
> I've also discovered that I can only enter watch expressions if I
> click in the New watch expression box before any breakpoints get hit.
> I don't have to enter anything, I just need to, for a better work
> 'activate' it. After that, I can use it later in my debugging.  if I
> don't do this, it doesn't accept input.

Sounds like:
http://code.google.com/p/fbug/issues/detail?id=1575
I'll fix is now.

> --ed

[Al]

Must "enabled" and "visible" be linked? I find the new version
frustrating to use, it's not enabled half the time, and when it is
enabled, it's popping up all over the place. I like to be able to
inspect HTML at any time via Ctrl-shift-c, having to click an icon
prior to doing that kind of defeats all the utility of the keyboard
shortcut. Is there any way in the new system to get an active-but-not-
visible firebug aside from opening and minimizing it (then, of course,
closing it before navigating to another page)?

Not a fan of the new "in your face" firebug (or the "click reload"
firebug, as I've come to use it).

Al

On Apr 1, 10:27 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Firebug 1.4a16 is available fromhttp://getfirebug.com/releases/firebug/1.4X.
> We are getting close to beta.
>

> One of the issues we need feedback on is the newactivationmodel. Of

[johnjbarton]

On May 1, 8:03 pm, Al <a...@rtfo.org> wrote:
> Must "enabled" and "visible" be linked?  I find the new version

1.4a23 has enabled and minimized, so they are not linked any longer.

> frustrating to use, it's not enabled half the time, and when it is
> enabled, it's popping up all over the place.  I like to be able to

If you can be more specific, maybe I can help. Just so we are talking
about the same things, we call the panels like Console, Net, and
Script "enabled" and web pages were Firebug is open are "active".

> inspect HTML at any time via Ctrl-shift-c, having to click an icon
> prior to doing that kind of defeats all the utility of the keyboard

If Ctrl-shift-C does not work, its just a bug, please report it so we
can fix it.

Inspect does not require the page to be activated at load time.

> shortcut.  Is there any way in the new system to get an active-but-not-
> visible firebug aside from opening and minimizing it (then, of course,
> closing it before navigating to another page)?

We have to have some way for you to signify that the page should be
debugged.

So why are you closing Firebug before navigating to another page?

>
> Not a fan of the new "in your face" firebug (or the "click reload"
> firebug, as I've come to use it).

1.3 reloaded automatically and people complained. 1.4 does not reload
automatically.

You only need to reload for Console, Script and Net panels.

[Richard Heyes]

> ...

How about an "On by default" option? Or am I missing something
(entirely plausible...)?

Thanks.

[johnjbarton]

v1.4a23, Firebug Status Bar Icon > Right click > On for all Web pages.

jjb

[Richard Heyes]

> v1.4a23, Firebug Status Bar Icon > Right click > On for all Web pages.

Sure, but if I do that then it keeps popping up, which at best is
annoying. How about an "On for all webpages but minimised because I
don't want to see it all the time"? Or something a little less
verbose? :-)

[johnjbarton]

I think it would help if we understood why you would want Firebug open
but minimized on a page you have never looked at before.

Just to point out: the Firebug status bar icon or F12 opens Firebug on
the first click and minimized it on the second.

Currently minimized pages are not restored minimized. The problem here
is that if you open firebug, minimize Firebug, exit the page, then
some time later you revisit the page what should happen. We could
restore minimized. But then the user would easily forget that they had
Firebug on for the page. I don't like these kinds of hidden surprises.

jjb

[Richard Heyes]

Hi,

> I think it would help if we understood why you would want Firebug open
> but minimized on a page you have never looked at before.

Well I'm doing a lot of JS development at the moment, in fact that's
all I'm doing. So I will always want it running, but because my screen
space is small, I want it out of the way. And I don't want to see it
unless I've clicked the button to bring it up. My prior version was
1.4.10 and that was just dandy. :-)

Cheers.

[johnjbarton]

Ok, so open firebug on the page, minimize it. Firebug will stay
minimized until you close the page right?

[Hernan Rodriguez Colmeiro]

On Mon, May 4, 2009 at 16:54, johnjbarton <johnj...@johnjbarton.com> wrote:
> Currently minimized pages are not restored minimized. The problem here
> is that if you open firebug, minimize Firebug, exit the page, then
> some time later you revisit the page what should happen. We could
> restore minimized. But then the user would easily forget that they had
> Firebug on for the page. I don't like these kinds of hidden surprises.

Couldn't this be configured by some kind of setting? If there's "On
for all web pages" why not "Minimized for all web pages"?
You may say this can clutter the UI, and you're probably right. But it
would be nice to have this option, at least in about:config, while we
search for a good alternative in the UI ;)

Hernán

[johnjbarton]

It's that I don't understand this feature and, since it will be
invisible, I think it can be a trap for users. For example, consider
the "break on errors" feature. People select it, they break on the
error, they love it. They go off and fix the error. The next day
Firebug is broken. It keeps breakpointing all over the place. That's
because they forgot the invisible break on error option was set.

But let's go back the "why minimize always". Is the reason for this
feature like this: "I don't mind Firebug's overhead, I'm good with it
being active all the time, every page, just in case I want to debug a
page"?

jjb


On May 4, 9:14 pm, Hernan Rodriguez Colmeiro <colme...@gmail.com>
wrote:

[Richard Heyes]

Hi,

> Ok, so open firebug on the page, minimize it. Firebug will stay
> minimized until you close the page right?

Nope - every time I hit refresh or go to another page it pops up.

[johnjbarton]

If you reload the page it should stay minimized. If not its a bug.

If you go to another page the result depends upon that other page. If
you had Firebug open, then Firebug should be open; if minimized,
minimized. If not its a bug.

http://code.google.com/p/fbug/issues/detail?id=1715
jjb

[dm]

Hi, using 1.4.0a24 and FF 3.5b5pre (Shiretoko 20090504075713) I
observe the following behaviour:

Hit refresh/f5 on a page with firebug minimised -> firebug pops open
again

regards,

d

[Hernan Rodriguez Colmeiro]

On Tue, May 5, 2009 at 12:24, johnjbarton <johnj...@johnjbarton.com> wrote:
> If you reload the page it should stay minimized. If not its a bug.

I've reported bug 1730 regarding this issue (I made it from another
account, thigs thathappen when you log with two different accounts
into google services...).

http://code.google.com/p/fbug/issues/detail?id=1730

Hernán

[Al]

On May 2, 10:09 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On May 1, 8:03 pm, Al <a...@rtfo.org> wrote:
>
> > Must "enabled" and "visible" be linked? I find the new version
>
> 1.4a23 has enabled and minimized, so they are not linked any longer.

Someone addressed this later in the thread, the problem for me is that
the minimized state is not preserved across loads.

> > inspect HTML at any time via Ctrl-shift-c, having to click an icon
> > prior to doing that kind of defeats all the utility of the keyboard
>
> If Ctrl-shift-C does not work, its just a bug, please report it so we
> can fix it.
> Inspect does not require the page to be activated at load time.

This is the biggest problem for me, I see a bug has been opened:
http://code.google.com/p/fbug/issues/detail?id=1686

> We have to have some way for you to signify that the page should be
> debugged.
>
> So why are you closing Firebug before navigating to another page?

Because it's taking up a bunch of space and keeps popping up. The
"stay minimized" thing would be great, I see that is logged here:
http://code.google.com/p/fbug/issues/detail?id=1730

>
> 1.3 reloaded automatically and people complained. 1.4 does not reload
> automatically.
>
> You only need to reload for Console, Script and Net panels.

I guess that wasn't an issue for me in 1.3 because I only had to
activate firebug once. We have a dynamic URL structure, so 1.4's URL-
specific memory is not helpful, as it doesn't see example.com/item/1
and example.com/item/2 as being the same page. If I navigate to a
page on our site and notice that it's slow, an AJAX call failed, etc,
it's nice to be able to say "well what happened?" rather than hope it
will happen again after activating firebug and reloading.

"I don't mind Firebug's overhead, I'm good with it being active all

the time, every page, just in case I want to debug a page" is my
personal motto. It's even better when it's every page on a domain,
which is why the old activation model was pretty ideal for me.

Thanks for the feedback,
Al

[Trevan Richins]

I agree with Al. The per page activation is a little weird especially when I don't think I changed a page but firebug does. I'd love it to just be per top level domain. So if I turn it on for example.com/index.html it will stay open for any page inside of example.com, such as test.example.com/test.html or example.com/index.php.

[Richard Heyes]

Ok, so I'm not the only one! I'm so happy! Kinda...

http://code.google.com/p/fbug/issues/detail?id=1730

Cheers!

[sir_brizz]

I'm am COMPLETELY baffled about why so much effort is going into all
these complex activation schemes when it seems like the easiest to
develop and easiest to use functionality is already self evident.

One option "On by default with domain blacklist" or "Off by default
with domain whitelist".

Then you either have Firebug always on (for those of us that just
prefer to have it on by default on every page we visit) and a way to
disable each piece of functionality per domain, or you have Firebug
always off (for those that prefer the performance benefits) and a way
to enable each piece of functionality per domain.

Where did all this click, click, click to enable, disable, blabbity
blabbity blabbity come from? 1.4 is completely confusing and
incomprehensible right now. Previous versions of Firebug were very
simple and minimalistic, they didn't require a bunch of knowledge
about how the extension operated just to use it in a worthwhile way.
Is 1.4's intent to change all that?

Brizz

[johnjbarton]

On May 7, 4:09 pm, sir_brizz <bj.car...@gmail.com> wrote:
> I'm am COMPLETELY baffled about why so much effort is going into all
> these complex activation schemes when it seems like the easiest to
> develop and easiest to use functionality is already self evident.
>
> One option "On by default with domain blacklist" or "Off by default
> with domain whitelist".

We dropped that as too complex.

>
> Then you either have Firebug always on (for those of us that just
> prefer to have it on by default on every page we visit) and a way to
> disable each piece of functionality per domain, or you have Firebug
> always off (for those that prefer the performance benefits) and a way
> to enable each piece of functionality per domain.

Also dropped too complex.

>
> Where did all this click, click, click to enable, disable, blabbity
> blabbity blabbity come from? 1.4 is completely confusing and
> incomprehensible right now. Previous versions of Firebug were very
> simple and minimalistic, they didn't require a bunch of knowledge
> about how the extension operated just to use it in a worthwhile way.

I don't know what you are referring to. If you can list the steps that
you find difficult then may be I can comment.

One problem with the discussion thread here is that it is a mix of bug
reports and learning how to explain the 1.4 mechanism. I believe the
final result will be simple enough.

jjb

[Richard Heyes]

> ...

Just updated to 1.4.25 and it appears to not be popping up on every
refresh - thanks!

[sir_brizz]

I don't see how either of those options are complex enough as to
combat the utterly confusing functionality that is there right now.
The problem is, the current 1.4 functionality *does not make sense*.
And any expansions upon the current functionality only continue to
make it not make sense.

I'm not sure how having a domain whitelist/blacklist is not preferable
to the current system. Right now, it's difficult to even tell if
Firebug is enabled/disabled or to get it to function properly once it
has supposedly been enabled. It's important to note that I and many
others raised this *exact same concern* several months ago when the
activation model was being discussed. The current method is not only
confusing but has multiple touchpoints where undesired behavior can
occur. The old activation model was better in the sense that, if you
wanted Firebug enabled a certain way, it wasn't hard to get it enabled
that way. Then it was fire and forget.

I'm not sure why a complex and confusing activation model was chosen
over simpler methods because those simpler methods were considered too
complex? o_O A little baffling there.

[johnjbarton]

On May 9, 1:25 am, sir_brizz <bj.car...@gmail.com> wrote:
> I don't see how either of those options are complex enough as to
> combat the utterly confusing functionality that is there right now.
> The problem is, the current 1.4 functionality *does not make sense*.
> And any expansions upon the current functionality only continue to
> make it not make sense.

If you can be more specific about the problem you see in the current
1.4 design, that would be very helpful.

> I'm not sure how having a domain whitelist/blacklist is not preferable
> to the current system. Right now, it's difficult to even tell if
> Firebug is enabled/disabled or to get it to function properly once it

This part of the design has not changed: if the Firebug status bar
icon is orange, then Firebug is active and if you hover over the icon,
the tooltip will give you details. If this was sufficient before, it
should also work now.

> has supposedly been enabled. It's important to note that I and many
> others raised this *exact same concern* several months ago when the
> activation model was being discussed. The current method is not only
> confusing but has multiple touchpoints where undesired behavior can

The concerns raised by people on this newsgroup lead to several
significant changes in the design. Again if you can point to specific
problems we can discuss whether our changes were sufficient. In
addition your concerns may be caused by bugs we don't know about
rather than problems with the design.

> occur. The old activation model was better in the sense that, if you
> wanted Firebug enabled a certain way, it wasn't hard to get it enabled
> that way. Then it was fire and forget.

I'm glad the old activation model worked for you. Honestly we did not
put additional work in to activation primarily to piss you off.
Working on the activation system is a the very bottom of my list of
things I want to do. But we thought we could make it a lot better for
most people. Hopefully it won't be a lot worse for some, but any
chance in a complex tool will make some people unhappy. Since you like
what we did in earlier versions, I hope you will give 1.4 a chance.

jjb

[Will Hughes]

I've been using 1.4.0a27 and the release immediately prior (I don't
remember the version, sorry), and I have to say that the activation
model is driving me absolutely batty.

I often use Firebug to debug webservice calls, and having the Firebug
Network panel not capture activity because I've opened a new tab or
window is incredibly frustrating.

I need a setting *somewhere* (even if not in the UI) so that I can
force the Network panel to activate always on certain sites or
globally - I don't particularly mind either way.

I really really love the JSON decoding, but the current model has
(cumulatively) lost me more hours than if I had stayed with 1.3 and
decoded the results manually.

On Apr 2, 3:27 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Firebug 1.4a16 is available fromhttp://getfirebug.com/releases/firebug/1.4X.
> We are getting close to beta.
>

> One of the issues we need feedback on is the new activation model. Of

[johnjbarton]

On May 10, 8:46 pm, Will Hughes <spec8...@gmail.com> wrote:
> I've been using 1.4.0a27 and the release immediately prior (I don't
> remember the version, sorry), and I have to say that the activation
> model is driving me absolutely batty.
>
> I often use Firebug to debug webservice calls, and having the Firebug
> Network panel not capture activity because I've opened a new tab or
> window is incredibly frustrating.

1.4a28 will activate any url you click on if it is in the same domain.
Will that help?

>
> I need a setting *somewhere* (even if not in the UI) so that I can
> force the Network panel to activate always on certain sites or
> globally - I don't particularly mind either way.

Firebug Status Icon > RightClick > On for all Web Pages

jjb

[Will Hughes]

On May 11, 1:56 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> 1.4a28 will activate any url you click on if it is in the same domain.
> Will that help?

Sometimes. However I do a lot of work with services that operate over
multiple domains. eg: www.domainA.example.org accessing
services.domainB.example.com. The links I follow might be to another
domain entirely eg: www.domainC.example.net - but then code on domainC
is calling back to domainB, and I need to be able to (if an error
occurrs) pop up the panel and figure out what service call went bad.

> Firebug Status Icon > RightClick > On for all Web Pages

Ah, missed that there - my bad. That'll do the trick!

[Landon]

Ok either I am not getting something or this just doesn't make any
sense, before we were told that to constantly monitor a pages traffic
we should open firebug in a new window and it would keep on the tab
activated even if we switched to a different tab. This is not how it
is working. Here is what I have tried and the only way that I have
found that works:

Open www.imagedash.com and switch to the net tab. (The site does a
post every second so it is easy to test this stuff with)
Open a new tab and switch to it. Wait for a few seconds and switch
back to imagedash. There is a break in the logging. With 1.3 firebug
happily kept right on doing what you had told it to do and logged all
net traffic for that tab.

Ok so at first the recommended way to solve this was top open firebug
in a new window from that tab so...:
Open imagedash, open firebug (if it wasn't open already) go to the net
tab and then either right click on the firebug icon>"Open firebug in a
new window", or click the little "^" button next to the close button.
Firebug pops out into a new window hooray! ...but all net monitoring
has stopped working. Refresh the page and it will start monitoring net
traffic again.
Ok so monitoring is working in the separate firebug window, now lets
switch to another tab... and the firebug window goes completely blank.
Great, that worked perfectly....

So just opening it on the tab and enabling the net panel and switching
to another tab and back breaks it (which worked in 1.3).
Opening it in a new window breaks it...

Every single option that I have found has failed to do what I am
attempting to do. The only method that I have found to get firebug to
work like I would like it to is to open a firefox window with ONLY the
page that I am working on open in it, enable firebug in that window,
and then open an entirely separate window to do any other browsing it.

Am I just crazy or is this how it is supposed to work now?

[Hernan Rodriguez Colmeiro]

> Am I just crazy or is this how it is supposed to work now?

The new activation model should be pretty simple to use, yet the
implementation might still be a little buggy.

The idea behind this activation model is the following:

1) You can have firebug opened attached to the window *OR* detached from it.

2) You can have only one firebug window detached *per* Firefox window.
That means, if you want to have two different firebug windows opened
at the same time, you should open two Firefox windows as well.

3) No matter how you opened Firebug, the User Interface should reflect
the status of firebug in the tab you have focus. This leads to some
sub-items:
3.1) You opened firebug attached to the window in "Tab A" where
firebug is enabled, and then switched to other "Tab B".
3.1.1) If firebug is not enabled in "Tab B", the UI shouldn't show up.
3.1.2) If firebug is enabled in "Tab B", you should see the UI
reflecting the status of firebug in "Tab B".
3.2) You opened firebug detached from the window. The behavior of
firebug should be the same as in 3.1, just that all the action happens
in the detached firebug window.

4) When you change from "Tab A" to "Tab B" in the browser, firebug
keeps running in "Tab A" but in background, while the UI reflects the
status of firebug in "Tab B". When you switch back from "Tab B" to
"Tab A", the running instance of firebug which was in the background
is restored, and the one from "Tab B" is the one that now goes to the
background.
This means that if you left firebug in one tab doing some AJAX, when
you switch back to that tab, the console or Net panel should list the
full log of the transfers, just like if you hadn't switched from that
tab at all.

But that's an ideal activation model, if some things doesn't behave as
expected it might be that your facing some bug in the code. And by the
way, it would be wonderful if you reported it ;)

Hernán

[johnjbarton]

On May 12, 12:04 pm, Landon <L4nd0n...@gmail.com> wrote:
...
> Every single option that I have found has failed to do what I am
> attempting to do. The only method that I have found to get firebug to
> work like I would like it to is to open a firefox window with ONLY the
> page that I am working on open in it, enable firebug in that window,
> and then open an entirely separate window to do any other browsing it.
>
> Am I just crazy or is this how it is supposed to work now?

Yes! I'm sorry you had to discover this by trial and error. I had
intended to post information about this approach to your kind of use
case. But first I wanted to get it to work so your evaluation of the
approach could be based on more or less correct operation.
Unfortunately the open in new window aka detached aka external mode is
subtle and I haven't got it all correct yet. Close but not yet.

To clarify, the use case where you monitor a page while using the
browser for other purpose will need one Firefox window for every page
you want to watch and each will have its own copy of Firebug (in
browser or detached).

jjb

[Nicholas Orr]

1.4.0a27 - loving how it works so far.

1. I open the browser (which is a purpose built ff portable install for web dev)
2. go to the page I want to use firebug on
3. click the icon, it goes "on"
4. click it again it opens the firebug window (attached)
5. click the arrow to detach it
6. open a new tab with a diff page and the detached firebug window "turns off"
7. go back to my original tab and firebug window "turns on" again and brings the window to top/focus

I think I've run into a few issues once or twice. I click the firebug icon and everything is ok again

At lease now I'm able to use both monitors easily with a firebug window and a firefox window on each monitor.

Cheers,

:)

[Ricardo]

On 2 abr, 02:27, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Firebug 1.4a16 is available fromhttp://getfirebug.com/releases/firebug/1.4X.
> We are getting close to beta.
>
> One of the issues we need feedback on is the new activation model. Of
> special importance are ideas for how to support use models that suffer
> in the new scheme without adding options to the UI.
>
> jjb

I've been using 1.4 for a about two weeks now and I'm not very fond of
it. I couldn't answer the simple question "is firebug on or off?". On
1.3 I'd usually enable it for any site I was working on, knowing it
would always be there waiting to appear on the press of a button. In
1.4 pressing F12 not only show/hides it but "activates" an instance
for the current page, or something like that. That's awkard. I never
used the minimize/close buttons before, only F12. If I went to a site
that I was curious about, I'd just enable it and refresh the page.

One thing that really bothers me in this new model is that it doesn't
show errors or allow you to inspect anything before it's visible.
Those are the two things I used the most, a quick look for errors on
the status bar and right-clicking an element / Inspect without having
to bring it up first. It's counter-productive.

Also I'm not sure about the impact on performance it has (and I
haven't noticed any difference) but GMail won't stop complaining and
freezing, and I like to keep it open all day.

I just uninstalled and went back to 1.3 for now, as it's still quite
buggy/slow and the large icons/top bar are annoying.

cheers
-- ricardo

[johnjbarton]

On May 14, 12:03 am, Ricardo <ricardob...@gmail.com> wrote:
...

>
> I've been using 1.4 for a about two weeks now and I'm not very fond of
> it. I couldn't answer the simple question "is firebug on or off?". On

The Firebug status bar icon is supposed to answer this question:
grey: panels disabled or suspended.
orange: panels enabled
hover text: status of Firebug.

> 1.3 I'd usually enable it for any site I was working on, knowing it
> would always be there waiting to appear on the press of a button. In

The difference in 1.4 is that Firebug will be waiting to appear on the
press of a button and you won't need to enable it.

> 1.4 pressing F12 not only show/hides it but "activates" an instance
> for the current page, or something like that. That's awkard. I never
> used the minimize/close buttons before, only F12. If I went to a site
> that I was curious about, I'd just enable it and refresh the page.

In 1.4 you just open Firebug and refresh the page.

>
> One thing that really bothers me in this new model is that it doesn't
> show errors or allow you to inspect anything before it's visible.
> Those are the two things I used the most, a quick look for errors on
> the status bar and right-clicking an element / Inspect without having
> to bring it up first. It's counter-productive.

There is not too much we can do about the 'show errors' problem: we
need help from Firefox and they don't seem interested in fixing it.
The problem is that we can't count errors for a page without
activating Firebug (this was not a problem back in the first versions
of Firebug because there were very few AJAX apps).

The right-click Inspect was just a bug that got fixed when it was
reported.

>
> Also I'm not sure about the impact on performance it has (and I
> haven't noticed any difference) but GMail won't stop complaining and
> freezing, and I like to keep it open all day.

If you have Gmail tab open, then Firebug should say: suspended. If not
then you need to close firebug on the Gmail page. Right now you do
that by opening firebug and closing it. Maybe we should have a context
menu item to help you.

>
> I just uninstalled and went back to 1.3 for now, as it's still quite
> buggy/slow and the large icons/top bar are annoying.

? you mean 1.3 is buggy and slow?

jjb

[Brade]

Completely agree with sir_brizz and will hughes. This new "activation
model" is patently insane and just made my life 100 times more
difficult. If someone were to create a fork of Firebug 1.3 that
preserved domain whitelisting/blacklisting, I would pay $50 for it
easily. johnjbarton, since you seem oblivious to how the new version
is problematic, let me spell out some common scenarios I have tried:

Previously I enabled firebug for localhost, since that's where I do
most of my testing and developing. Then I would browse from page to
page (without the panel open) until the "script error" message came up
on the status bar. Then I'd open the firebug panel and troubleshoot.
I'd fix it then perhaps browse around a few more pages, with the panel
still open. When I was happy I'd solved the problem, I minimized
firebug (back in those halcyon days, I could click the "x" button or
the little firebug icon to remove the panel--it didn't matter). But
firebug stayed active, so I would be alerted to script errors if they
happened.

Fast forward to today. Seems firebug now remembers panel position PER
PAGE, which is ludicrously stupid. So as I browse from one page to the
next, the panel is randomly disappearing and reappearing. And of
course I can no longer simply tell firebug to be active only for
localhost. WOW, WHAT SOME GREAT NEW FEATURES, GUYS!

The new system is completely absurd, and I hope now you can begin to
see why. When a tool as ubiquitous as firebug gets changed so
drastically, the question is WHY? We all loved it before, so please
stop butchering it. And again, I put out the call to some developer
out there who would want to continue the awesomeness of firebug 1.3
and perhaps rename it. That person would be regarded as a hero at this
point...

--brad g.


On May 10, 11:46 pm, Will Hughes <spec8...@gmail.com> wrote:
> I've been using1.4.0a27 and the release immediately prior (I don't

> remember the version, sorry), and I have to say that the activation
> model is driving me absolutely batty.
>
> I often use Firebug to debug webservice calls, and having the Firebug

> Networkpanelnot capture activity because I've opened a new tab or

> window is incredibly frustrating.
>
> I need a setting *somewhere* (even if not in the UI) so that I can

> force the Networkpanelto activate always on certain sites or

> globally - I don't particularly mind either way.
>
> I really really love the JSON decoding, but the current model has
> (cumulatively) lost me more hours than if I had stayed with 1.3 and
> decoded the results manually.
>
> On Apr 2, 3:27 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
>

> > Firebug1.4a16 is available fromhttp://getfirebug.com/releases/firebug/1.4X.

[johnjbarton]

Work on Firebug 1.4 is complete. Your scenario description is a good
one, I wish we had it back when we were working on this feature. I'd
love for Firebug to be perfect for everyone, but in every change there
will be some winners and losers I guess.

The activation model in 1.4 was designed to allow extensions to
provide special activation solutions. If anyone wants to create one
for this use case we'd be happy to give advice. (Just to set
expectations, I have no plans to do any more work on activation
myself).

jjb

[Bill Barry]

I really like how the new activation scheme works. It is much simpler than the 1.3 model (which I really didn't like at all).

I would just like it to:
1. always activate when I visit a particular page where I previously _opened_ it (as it currently does)
2. stay active for the duration of that tab without flagging any other pages which visit as pages for which it should open
3. don't unflag pages that I happen to come across unless I close the panel while on them and they were flagged

[Bill Barry]

Is there any documentation on this extension mechanism?

I would be happy to try my hand at writing one (if possible to do the
scenario in the other post, if not then I guess domain whitelisting
would be good enough).

[johnjbarton]

Firebug extension generally:
http://www.softwareishard.com/blog/firebug-tutorial/extending-firebug-hello-world-part-i/

The component in Firebug that implements the feature:
http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/firebug.js#3359

You also need to hook the callback in your module's initializeUI
TabWatcher.addListener(Firebug.URLSelector); // listen
for shouldCreateContext
uiListeners.push(Firebug.URLSelector); // listen for
showUI

jjb

[Trevan Richins]

I'm having problems getting this to work. I've got an extension up and running and can see it calling my shouldCreateContext function. But returning true from it doesn't always open up firebug. Am I missing something? Do I need to do all the annotation stuff?

Also, the Firebug.URLSelector doesn't have a showUI function so I didn't implement that function.

Trevan

-----Original Message-----
From: fir...@googlegroups.com [mailto:fir...@googlegroups.com] On Behalf Of johnjbarton
Sent: Tuesday, June 23, 2009 9:22 AM
To: Firebug
Subject: Re: New activation model in Firebug 1.4

[johnjbarton]

It would be helpful to start a new thread on this subject...

Open the tracing console and set option ACTIVATION. If you return true
from your shouldCreateContext() and shouldShowContext(), then the
trace should say that the context in an INIT dispatch.

You're right it looks like the showUI comment is not correct.

jjb

On Jun 23, 10:22 am, Trevan Richins <TRich...@omniture.com> wrote:
> I'm having problems getting this to work.  I've got an extension up and running and can see it calling my shouldCreateContext function.  But returning true from it doesn't always open up firebug.  Am I missing something?  Do I need to do all the annotation stuff?
>
> Also, the Firebug.URLSelector doesn't have a showUI function so I didn't implement that function.
>
> Trevan
>
> -----Original Message-----
> From: fir...@googlegroups.com [mailto:fir...@googlegroups.com] On Behalf Of johnjbarton
> Sent: Tuesday, June 23, 2009 9:22 AM
> To: Firebug
> Subject: Re: New activation model in Firebug 1.4
>

> Firebug extension generally:http://www.softwareishard.com/blog/firebug-tutorial/extending-firebug...
>
> The component in Firebug that implements the feature:http://code.google.com/p/fbug/source/browse/branches/firebug1.5/conte...

[Francis Lewis]

The only reason I'm using 1.4 is because I'm using FireFox 3.5,
otherwise I would still be using 1.3 as I liked how the activation
model on that one worked.
As I mentioned before in the announcement topic for the new activation
model, I really hate it.
When I was using 1.3, I would turn it on for the domains I was
developing for and it was always on.
Now, when I turn it on and login to the site I'm working on, after I
login, it turns off. The AJAX I have running happens on login, so it's
very difficult to debug now.

I'm using FirePHP which works like the FireBug 1.3 activation model
did and I like it so much better.
Any way we could get an add-on or tutorial on how to change the
activation model to work like it did in 1.3? it would be really nice
to have the option for those that don't like the new model.

[johnjbarton]

On Jun 24, 9:34 am, Francis Lewis <ftu...@gmail.com> wrote:
...

> Now, when I turn it on and login to the site I'm working on, after I
> login, it turns off. The AJAX I have running happens on login, so it's
> very difficult to debug now.

Of course from the browser's point of view, you turned Firebug on for
the login page, but not for the page after that.

What happens if you open Firebug on the page after the login?

If you can create a test case that simulates the effect you see, I
will look into supporting it under the 1.4 activation solution.

jjb

[HIghway of Life]

I wrote this post in a new topic without noticing this existing topic,
I will copy here as it is the more relevant location.
I’m extremely disappointed with the new activation model, it's
infuriating to work with.

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

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

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

[Ryan]

I totally agree with this post.

[johnjbarton]

On Jun 30, 11:41 am, HIghway of Life <highwayofl...@gmail.com> wrote:
...

> otherwise seen. Now with the new model, the only way to keep Firebug
> active is to close (hide) Firebug, but this is very undesired as it
> opens on every page load and has proven to drive up the annoyance
> factor to intolerable levels.

I don't understand what you are saying here. This is not how Firebug
1.4 works.

For information on how it does work, check out this great post:
http://www.softwareishard.com/blog/firebug/how-to-enable-and-disable-firebug-14/

jjb

[Luke Maurer]

> Work on Firebug 1.4 is complete. Your scenario description is a good
> one, I wish we had it back when we were working on this feature. I'd
> love for Firebug to be perfect for everyone, but in every change there
> will be some winners and losers I guess.

This is exactly why the design shouldn't be considered closed when you
go into beta. Any major and disruptive workflow change like this needs
the benefit of *as much user input as possible*, even if it *is* the
major improvement you believe it to be.

Also, I have yet to understand who exactly the winners are -
especially since you haven't given any compelling reason for
*removing* domain filtering. Sure, a more fluid and dynamic way to
activate Firebug seems nice, especially for new users, but it also
seems completely orthogonal to being able to say "just activate
everything always for this site."

> The activation model in 1.4 was designed to allow extensions to
> provide special activation solutions.  If anyone wants to create one
> for this use case we'd be happy to give advice. (Just to set
> expectations, I have no plans to do any more work on activation
> myself).

Will those extensions allow for as convenient an interface to domain
filtering as 1.3 had? Being able to activate a tab permanently for the
current domain was quick and easy before; are we now going to have to
dig into a separate extension preferences dialog if a plugin
implements it?

- Luke

[johnjbarton]

On Jun 30, 3:03 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> > Work on Firebug 1.4 is complete. Your scenario description is a good
> > one, I wish we had it back when we were working on this feature. I'd
> > love for Firebug to be perfect for everyone, but in every change there
> > will be some winners and losers I guess.
>
> This is exactly why the design shouldn't be considered closed when you
> go into beta. Any major and disruptive workflow change like this needs
> the benefit of *as much user input as possible*, even if it *is* the
> major improvement you believe it to be.

If you can be more concrete about the specific problem you have, then
it will be easier to respond. I don't understand how the activation
model could disrupt the workflow.

>
> Also, I have yet to understand who exactly the winners are -
> especially since you haven't given any compelling reason for
> *removing* domain filtering. Sure, a more fluid and dynamic way to
> activate Firebug seems nice, especially for new users, but it also
> seems completely orthogonal to being able to say "just activate
> everything always for this site."

If you want to activate everything for a site:
Firebug StatusBar icon, right click "Enable All Panels". You only
have to do this one time.
Load the site.
Open Firebug on the site.
Reload the page.

Firebug will be active for that page and every link you take off of
that page from now on. No funky options panel, no worries by black/
white lists.

>
> > The activation model in 1.4 was designed to allow extensions to
> > provide special activation solutions.  If anyone wants to create one
> > for this use case we'd be happy to give advice. (Just to set
> > expectations, I have no plans to do any more work on activation
> > myself).
>
> Will those extensions allow for as convenient an interface to domain
> filtering as 1.3 had? Being able to activate a tab permanently for the
> current domain was quick and easy before; are we now going to have to
> dig into a separate extension preferences dialog if a plugin
> implements it?

Extensions can implement exactly the 1.3 model if they choose to do
so. Extension have full access to the UI.

jjb

[Tama]

Oops I missed this thread.

I've just upgraded to FF3.5 as I'm sure a lot of developers have and
using Firebug 1.4+ is driving me INSANE!!!

All I want is for Firebug to be on ALL the time for every page load on
certain sites that I specify.
i.e. I'm developing a website so I want every page load to be debugged
by Firebug regardless of whether the panel is open or not, it is soooo
frustrating to have to open the panel then refresh, it's just not
practical.

I love Firebug but this is crazyness - I'm going to have to go back to
Firebug 1.3 and Firefox 3.0.x.

[HIghway of Life]

On Jun 30, 7:20 pm, Tama <tama.pugs...@gmail.com> wrote:
> I've just upgraded to FF3.5 as I'm sure a lot of developers have and
> using Firebug 1.4+ is driving me INSANE!!!
>
> All I want is for Firebug to be on ALL the time for every page load on
> certain sites that I specify.
> i.e. I'm developing a website so I want every page load to be debugged
> by Firebug regardless of whether the panel is open or not, it is soooo
> frustrating to have to open the panel then refresh, it's just not
> practical.

Tama, is your issue related or similar to this?
http://highwayoflife.net/jing/Firebug_Activation_Issues.swf