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
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!
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?
> 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 ;)
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).
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.
> 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.
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.
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:
> > 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.
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
On Jun 23, 6:05 am, Brade <bradez...@gmail.com> wrote:
> 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:
> > > 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.
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
Brade wrote:
> 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:
>>> 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.
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 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.
> 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).
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
On Jun 23, 7:55 am, Bill Barry <after.fall...@gmail.com> wrote:
> 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 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.
> > 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).
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.
-----Original Message-----
From: firebug@googlegroups.com [mailto:firebug@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
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
On Jun 23, 7:55 am, Bill Barry <after.fall...@gmail.com> wrote:
> 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 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.
> > 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).
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: firebug@googlegroups.com [mailto:firebug@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
> 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
> On Jun 23, 7:55 am, Bill Barry <after.fall...@gmail.com> wrote:
> > 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 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.
> > > 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).
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.
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.
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.
> 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.
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.
> 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?
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.
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.
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.
|
