Apologies in advance if this was already covered somewhere in the recent threads:
I¹m using Firefox 3.5 (final) and Firebug 1.4.0b3.
A very common workflow for me, and I suspect a lot of developers, is to have Firebug open (in-browser) for a (local) site I¹m developing, then make a change, say in some javascript code, come back to Firefox, clear its cache so it gets the change, then reload the page.
Maybe I¹m missing some obvious Firebug setting, but for me, the page reload closes the Firebug window (why?), forcing me to reopen it, then I must load the page a *second* time before I¹m finally debugging my changed code.
You should just be able to go to Firefox and hit control-F5. That will
reload the page without reading from the cache. Firebug will not
close.
If FIrebug closes, then it is a bug. We've not heard of this before,
its not the way it should work.
One thing to check:
Either: about:config then type "firebug" to see if any settings are
not defaults.
Or: Firebug ICon menu > Options > reset all options.
Just in case something from 1.3 is left around.
jjb
On Jun 30, 2:15 pm, Greg Beddow <gbed...@comcast.net> wrote:
> Apologies in advance if this was already covered somewhere in the recent
> threads:
> I¹m using Firefox 3.5 (final) and Firebug 1.4.0b3.
> A very common workflow for me, and I suspect a lot of developers, is to have
> Firebug open (in-browser) for a (local) site I¹m developing, then make a
> change, say in some javascript code, come back to Firefox, clear its cache
> so it gets the change, then reload the page.
> Maybe I¹m missing some obvious Firebug setting, but for me, the page reload
> closes the Firebug window (why?), forcing me to reopen it, then I must load
> the page a *second* time before I¹m finally debugging my changed code.
I too have been looking for an option to keep the FB pane open like it
did pre FF 3.5 using 1.5X.0a06 (I was using 1.4... but I thought this
might've been a bug so upgrade to 1.5...).
It's either one or both of these two things
1. The pane now closes when you navigate to a new page. Meaning you
always have to reopen the pane and then refresh the page because of
#2.
2. The pane doesn't log anything until it's open, even when the site
has been activated.
This basically means whenever I click a link to a new page on my dev
site I have to open the firebug page then click refresh. Which doesn't
actually work on some pages (e.g. logout).
On Jun 30, 7:06 pm, Tama <tama.pugs...@gmail.com> wrote:
> I too have been looking for an option to keep the FB pane open like it
> did pre FF 3.5 using 1.5X.0a06 (I was using 1.4... but I thought this
> might've been a bug so upgrade to 1.5...).
> It's either one or both of these two things
> 1. The pane now closes when you navigate to a new page. Meaning you
> always have to reopen the pane and then refresh the page because of
> #2.
The result when you navigate to a new page on a different domain,
firebug closes. It should do that in 1.3 as well unless the new domain
is one pre-selected by you.
> 2. The pane doesn't log anything until it's open, even when the site
> has been activated.
I don't understand what you are saying, but Firebug has to be active
when the page is loaded. This is true in 1.3 as well. However 1.3
automatically reloaded if you opened Firebug. Some people hated that
because they just wanted to use the CSS/HTML features, not the net/
script/console and did not want to wait for the reload.
> This basically means whenever I click a link to a new page on my dev
> site I have to open the firebug page then click refresh. Which doesn't
> actually work on some pages (e.g. logout).
On Jun 30, 8:02 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jun 30, 7:06 pm, Tama <tama.pugs...@gmail.com> wrote:
> > This basically means whenever I click a link to a new page on my dev
> > site I have to open the firebug page then click refresh. Which doesn't
> > actually work on some pages (e.g. logout).
> ? what is logout?
> jjb
On my development site (for example), the logout screen causes Firebug
to close down. I have to re-activate Firebug every time I login after
logging out.
> On Jun 30, 8:02 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > On Jun 30, 7:06 pm, Tama <tama.pugs...@gmail.com> wrote:
> > > This basically means whenever I click a link to a new page on my dev
> > > site I have to open the firebug page then click refresh. Which doesn't
> > > actually work on some pages (e.g. logout).
> > ? what is logout?
> > jjb
> On my development site (for example), the logout screen causes Firebug
> to close down. I have to re-activate Firebug every time I login after
> logging out.
This new activation model is NOT workflow friendly for a web-dev, as I
often browse sites with the panel open, and want to see what they've
loaded WITHOUT hitting control-5. I can't keep the firebug window
open all the time, and it looks as if the only way to keep track of
net requests (as in the old model) is to keep the panel open.
Even telling firebug to 'enable all panels' and 'on for all pages'
will cause it to not capture net requests when the panel is minimized,
instead display this cryptic error message:
'Net panel activated. Any requests while the net panel is inactive are
not shown.'
Sure enough, it didn't log any net requests when the panel was
minimized. This is a regression issue and VERY annoying, as reloading
a page with control-f5 isn't an option for monitoring ajax requests
that have already happened.
Thanks,
J
On Jun 30, 8:02 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jun 30, 7:06 pm, Tama <tama.pugs...@gmail.com> wrote:
> > I too have been looking for an option to keep the FB pane open like it
> > did pre FF 3.5 using 1.5X.0a06 (I was using 1.4... but I thought this
> > might've been a bug so upgrade to 1.5...).
> > It's either one or both of these two things
> > 1. The pane now closes when you navigate to a new page. Meaning you
> > always have to reopen the pane and then refresh the page because of
> > #2.
> The result when you navigate to a new page on a different domain,
> firebug closes. It should do that in 1.3 as well unless the new domain
> is one pre-selected by you.
> > 2. The pane doesn't log anything until it's open, even when the site
> > has been activated.
> I don't understand what you are saying, but Firebug has to be active
> when the page is loaded. This is true in 1.3 as well. However 1.3
> automatically reloaded if you opened Firebug. Some people hated that
> because they just wanted to use the CSS/HTML features, not the net/
> script/console and did not want to wait for the reload.
> > This basically means whenever I click a link to a new page on my dev
> > site I have to open the firebug page then click refresh. Which doesn't
> > actually work on some pages (e.g. logout).
I didn't care for the activation model at the very beginning, but they've fixed a bunch of bugs related to it. Now, it is pretty decent for me. When I'm browsing the web to see what others are doing, marking "on for all pages" works perfectly. When I'm developing, most of my pages have been activated previously so they are activated the next time. I still mistakenly deactivate firebug instead of minimize it and that causes me grief, but I'm getting used to it. So, for those that are up in arms against it, just use it for a bit. It remembers the pages that you have previously activated firebug on. It attempts to keep firebug on in the same domain if it is already been open (I've seen some issues with this but never been able to reliably reproduce it so haven't filed a bug on it).
-----Original Message-----
From: firebug@googlegroups.com [mailto:firebug@googlegroups.com] On Behalf Of jjj
Sent: Wednesday, July 01, 2009 12:34 PM
To: Firebug
Subject: Re: New Activation Model
re: #2
This new activation model is NOT workflow friendly for a web-dev, as I
often browse sites with the panel open, and want to see what they've
loaded WITHOUT hitting control-5. I can't keep the firebug window
open all the time, and it looks as if the only way to keep track of
net requests (as in the old model) is to keep the panel open.
Even telling firebug to 'enable all panels' and 'on for all pages'
will cause it to not capture net requests when the panel is minimized,
instead display this cryptic error message:
'Net panel activated. Any requests while the net panel is inactive are
not shown.'
Sure enough, it didn't log any net requests when the panel was
minimized. This is a regression issue and VERY annoying, as reloading
a page with control-f5 isn't an option for monitoring ajax requests
that have already happened.
Thanks,
J
On Jun 30, 8:02 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jun 30, 7:06 pm, Tama <tama.pugs...@gmail.com> wrote:
> > I too have been looking for an option to keep the FB pane open like it
> > did pre FF 3.5 using 1.5X.0a06 (I was using 1.4... but I thought this
> > might've been a bug so upgrade to 1.5...).
> > It's either one or both of these two things
> > 1. The pane now closes when you navigate to a new page. Meaning you
> > always have to reopen the pane and then refresh the page because of
> > #2.
> The result when you navigate to a new page on a different domain,
> firebug closes. It should do that in 1.3 as well unless the new domain
> is one pre-selected by you.
> > 2. The pane doesn't log anything until it's open, even when the site
> > has been activated.
> I don't understand what you are saying, but Firebug has to be active
> when the page is loaded. This is true in 1.3 as well. However 1.3
> automatically reloaded if you opened Firebug. Some people hated that
> because they just wanted to use the CSS/HTML features, not the net/
> script/console and did not want to wait for the reload.
> > This basically means whenever I click a link to a new page on my dev
> > site I have to open the firebug page then click refresh. Which doesn't
> > actually work on some pages (e.g. logout).
On Jul 1, 8:21 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> Firebug does not know about your logout. It only knows about URLs.
> jjb
Right, but the point is that it's failing, whereas on 1.3, it never
failed here. Is it part of the new 'activation model' that is causing
it to fail (disable/turn off)?
My problem was clicking the X to minimize Firebug as I have been for
the past 2-3 years. Clicking minimize has solved most of my
frustrations.
Using X to close Firebug makes sense UI-wise but no sense when version
1.3 used it to minimize.
Adding a notification the first time you click X saying "Did you
realise you have turned Firebug off? Use the minimize arrow, if you
would like Firebug to continue when minimized".
On Jul 1, 2:50 pm, Trevan Richins <TRich...@omniture.com> wrote:
> I didn't care for the activation model at the very beginning, but they've fixed a bunch of bugs related to it. Now, it is pretty decent for me. When I'm browsing the web to see what others are doing, marking "on for all pages" works perfectly. When I'm developing, most of my pages have been activated previously so they are activated the next time. I still mistakenly deactivate firebug instead of minimize it and that causes me grief, but I'm getting used to it. So, for those that are up in arms against it, just use it for a bit. It remembers the pages that you have previously activated firebug on. It attempts to keep firebug on in the same domain if it is already been open (I've seen some issues with this but never been able to reliably reproduce it so haven't filed a bug on it).
> -----Original Message-----
> From: firebug@googlegroups.com [mailto:firebug@googlegroups.com] On Behalf Of jjj
> Sent: Wednesday, July 01, 2009 12:34 PM
> To: Firebug
> Subject: Re: New Activation Model
> re: #2
> This new activation model is NOT workflow friendly for a web-dev, as I
> often browse sites with the panel open, and want to see what they've
> loaded WITHOUT hitting control-5. I can't keep the firebug window
> open all the time, and it looks as if the only way to keep track of
> net requests (as in the old model) is to keep the panel open.
> Even telling firebug to 'enable all panels' and 'on for all pages'
> will cause it to not capture net requests when the panel is minimized,
> instead display this cryptic error message:
> 'Net panel activated. Any requests while the net panel is inactive are
> not shown.'
> Sure enough, it didn't log any net requests when the panel was
> minimized. This is a regression issue and VERY annoying, as reloading
> a page with control-f5 isn't an option for monitoring ajax requests
> that have already happened.
> Thanks,
> J
> On Jun 30, 8:02 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > On Jun 30, 7:06 pm, Tama <tama.pugs...@gmail.com> wrote:
> > > I too have been looking for an option to keep the FB pane open like it
> > > did pre FF 3.5 using 1.5X.0a06 (I was using 1.4... but I thought this
> > > might've been a bug so upgrade to 1.5...).
> > > It's either one or both of these two things
> > > 1. The pane now closes when you navigate to a new page. Meaning you
> > > always have to reopen the pane and then refresh the page because of
> > > #2.
> > The result when you navigate to a new page on a different domain,
> > firebug closes. It should do that in 1.3 as well unless the new domain
> > is one pre-selected by you.
> > > 2. The pane doesn't log anything until it's open, even when the site
> > > has been activated.
> > I don't understand what you are saying, but Firebug has to be active
> > when the page is loaded. This is true in 1.3 as well. However 1.3
> > automatically reloaded if you opened Firebug. Some people hated that
> > because they just wanted to use the CSS/HTML features, not the net/
> > script/console and did not want to wait for the reload.
> > > This basically means whenever I click a link to a new page on my dev
> > > site I have to open the firebug page then click refresh. Which doesn't
> > > actually work on some pages (e.g. logout).
On Jul 1, 11:50 am, Trevan Richins <TRich...@omniture.com> wrote:
> I still mistakenly deactivate firebug instead of minimize it and that causes me grief, but I'm getting used to it.
I wouldn't call that "mistaken," I'd call it perfectly reasonable. How
many UIs do you know that tie a background process like Ajax
monitoring inextricably to whether a certain window is open or not?
And by well-understood convention, if you "close" a window but the app
has a little icon in the bottom-right, it's still doing stuff in the
background (think of IM clients and the system tray). So there's every
reason for a user (*especially* those new users that the new
activation model is supposed to cater to) not to pay attention to the
difference between minimizing and closing - close means "get this bit
of UI out of the way," and minimize means "get it mostly out of the
way."
In short, the little X does not mean deactivate, it means close.
Having it do something other than close the window is unintuitive
*and* counterproductive.
> So, for those that are up in arms against it, just use it for a bit. It remembers the pages that you have previously activated firebug on. It attempts to keep firebug on in the same domain if it is already been open (I've seen some issues with this but never been able to reliably reproduce it so haven't filed a bug on it).
But this is always exactly the problem with software that tries to be
clever about what the user wants. It never quite works out, and the
user ends up spending more time working around the software's mistakes
than was ever saved by the cleverness to begin with.
> -----Original Message-----
> From: firebug@googlegroups.com [mailto:firebug@googlegroups.com] On Behalf Of jjj
> Sent: Wednesday, July 01, 2009 12:34 PM
> To: Firebug
> Subject: Re: New Activation Model
> re: #2
> This new activation model is NOT workflow friendly for a web-dev, as I
> often browse sites with the panel open, and want to see what they've
> loaded WITHOUT hitting control-5. I can't keep the firebug window
> open all the time, and it looks as if the only way to keep track of
> net requests (as in the old model) is to keep the panel open.
> Even telling firebug to 'enable all panels' and 'on for all pages'
> will cause it to not capture net requests when the panel is minimized,
> instead display this cryptic error message:
> 'Net panel activated. Any requests while the net panel is inactive are
> not shown.'
> Sure enough, it didn't log any net requests when the panel was
> minimized. This is a regression issue and VERY annoying, as reloading
> a page with control-f5 isn't an option for monitoring ajax requests
> that have already happened.
> Thanks,
> J
> On Jun 30, 8:02 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > On Jun 30, 7:06 pm, Tama <tama.pugs...@gmail.com> wrote:
> > > I too have been looking for an option to keep the FB pane open like it
> > > did pre FF 3.5 using 1.5X.0a06 (I was using 1.4... but I thought this
> > > might've been a bug so upgrade to 1.5...).
> > > It's either one or both of these two things
> > > 1. The pane now closes when you navigate to a new page. Meaning you
> > > always have to reopen the pane and then refresh the page because of
> > > #2.
> > The result when you navigate to a new page on a different domain,
> > firebug closes. It should do that in 1.3 as well unless the new domain
> > is one pre-selected by you.
> > > 2. The pane doesn't log anything until it's open, even when the site
> > > has been activated.
> > I don't understand what you are saying, but Firebug has to be active
> > when the page is loaded. This is true in 1.3 as well. However 1.3
> > automatically reloaded if you opened Firebug. Some people hated that
> > because they just wanted to use the CSS/HTML features, not the net/
> > script/console and did not want to wait for the reload.
> > > This basically means whenever I click a link to a new page on my dev
> > > site I have to open the firebug page then click refresh. Which doesn't
> > > actually work on some pages (e.g. logout).
On Jul 1, 11:33 am, jjj <jason31...@gmail.com> wrote:
> re: #2
> This new activation model is NOT workflow friendly for a web-dev, as I
> often browse sites with the panel open, and want to see what they've
> loaded WITHOUT hitting control-5. I can't keep the firebug window
> open all the time, and it looks as if the only way to keep track of
> net requests (as in the old model) is to keep the panel open.
For this use, I suggest using "open for all pages" (on the status bar
icon right click menu) and "minimize" the [_] icon in the upper right
corner.
> Even telling firebug to 'enable all panels' and 'on for all pages'
> will cause it to not capture net requests when the panel is minimized,
Under the settings I expect all net requests to be logged. If you have
a case where it fails we will fix it.
On Jul 1, 12:31 pm, HIghway of Life <highwayofl...@gmail.com> wrote:
> On Jul 1, 8:21 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:> Firebug does not know about your logout. It only knows about URLs.
> > jjb
> Right, but the point is that it's failing, whereas on 1.3, it never
> failed here. Is it part of the new 'activation model' that is causing
> it to fail (disable/turn off)?
Unfortunately I am not able to see the URLs in your browser from over
here. So I cannot tell if this is a bug or not.
On Jul 1, 12:56 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> On Jul 1, 11:50 am, Trevan Richins <TRich...@omniture.com> wrote:
> > I still mistakenly deactivate firebug instead of minimize it and that causes me grief, but I'm getting used to it.
> I wouldn't call that "mistaken," I'd call it perfectly reasonable. How
> many UIs do you know that tie a background process like Ajax
> monitoring inextricably to whether a certain window is open or not?
I don't what this has to do with Firebug.
> And by well-understood convention, if you "close" a window but the app
> has a little icon in the bottom-right, it's still doing stuff in the
> background (think of IM clients and the system tray). So there's every
> reason for a user (*especially* those new users that the new
> activation model is supposed to cater to) not to pay attention to the
> difference between minimizing and closing - close means "get this bit
> of UI out of the way," and minimize means "get it mostly out of the
> way."
I think Firebug user will get the hang of it pretty fast, they are are
a smart group.
> In short, the little X does not mean deactivate, it means close.
> Having it do something other than close the window is unintuitive
> *and* counterproductive.
I'm not sure what distinction you are making here. If Firebug is open
in the browser and you close it, it is not active for the browser tab.
That seem intuitive to me.
> > So, for those that are up in arms against it, just use it for a bit. It remembers the pages that you have previously activated firebug on. It attempts to keep firebug on in the same domain if it is already been open (I've seen some issues with this but never been able to reliably reproduce it so haven't filed a bug on it).
> But this is always exactly the problem with software that tries to be
> clever about what the user wants. It never quite works out, and the
> user ends up spending more time working around the software's mistakes
> than was ever saved by the cleverness to begin with.
If you have specific problems I would like to hear about them.
> Hope that helps. Thanks!!
> - Highway of Life
> Software Engineer
Cross-posting, but here's hoping it will help others.
Installing Firebug 1.5a7 fixed the issue with Firebug turning on and
off randomly on a domain.
http://getfirebug.com/releases/firebug/1.5X/
I tried this approach - firebug will pop open every time and I click
on the X - because I want that window closed - but the functionality
enabled. The firebug icon turns grey, and disables it.
Tell me how I can keep the network monitoring active while keeping the
network panel closed all the time until I click on the icon to open it
- ala previous versions?
>> Even telling firebug to 'enable all panels' and 'on for all pages'
>> will cause it to not capture net requests when the panel is minimized,
>Under the settings I expect all net requests to be logged. If you have
>a case where it fails we will fix it.
Right now, when repliyng via Google Groups - i have enable all panels
and on for all pages. I can hit control-n and guess what? the
firebug icon is greyed out. Sounds like you guys dropped the ball on
that one.
On Jul 1, 1:14 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 1, 11:33 am, jjj <jason31...@gmail.com> wrote:
> > re: #2
> > This new activation model is NOT workflow friendly for a web-dev, as I
> > often browse sites with the panel open, and want to see what they've
> > loaded WITHOUT hitting control-5. I can't keep the firebug window
> > open all the time, and it looks as if the only way to keep track of
> > net requests (as in the old model) is to keep the panel open.
> For this use, I suggest using "open for all pages" (on the status bar
> icon right click menu) and "minimize" the [_] icon in the upper right
> corner.
> > Even telling firebug to 'enable all panels' and 'on for all pages'
> > will cause it to not capture net requests when the panel is minimized,
> Under the settings I expect all net requests to be logged. If you have
> a case where it fails we will fix it.
This even happens with 1.5x.0a07 - I turned it "on for all pages", and
the checkbox is checked. I'm at the google groups page (http://
groups.google.com/group/firebug/browse_thread/thread/af951e7538f2dde2?
hl=en). I even have the net panel open as i typing this, and can hit
control-n and the firebug icon is disabled.
Tell me again how that's not broken?
On Jul 1, 5:41 pm, jjj <jason31...@gmail.com> wrote:
> I tried this approach - firebug will pop open every time and I click
> on the X - because I want that window closed - but the functionality
> enabled. The firebug icon turns grey, and disables it.
> Tell me how I can keep the network monitoring active while keeping the
> network panel closed all the time until I click on the icon to open it
> - ala previous versions?
> >> Even telling firebug to 'enable all panels' and 'on for all pages'
> >> will cause it to not capture net requests when the panel is minimized,
> >Under the settings I expect all net requests to be logged. If you have
> >a case where it fails we will fix it.
> Right now, when repliyng via Google Groups - i have enable all panels
> and on for all pages. I can hit control-n and guess what? the
> firebug icon is greyed out. Sounds like you guys dropped the ball on
> that one.
> On Jul 1, 1:14 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > On Jul 1, 11:33 am, jjj <jason31...@gmail.com> wrote:
> > > re: #2
> > > This new activation model is NOT workflow friendly for a web-dev, as I
> > > often browse sites with the panel open, and want to see what they've
> > > loaded WITHOUT hitting control-5. I can't keep the firebug window
> > > open all the time, and it looks as if the only way to keep track of
> > > net requests (as in the old model) is to keep the panel open.
> > For this use, I suggest using "open for all pages" (on the status bar
> > icon right click menu) and "minimize" the [_] icon in the upper right
> > corner.
> > > Even telling firebug to 'enable all panels' and 'on for all pages'
> > > will cause it to not capture net requests when the panel is minimized,
> > Under the settings I expect all net requests to be logged. If you have
> > a case where it fails we will fix it.
On Jul 1, 5:41 pm, jjj <jason31...@gmail.com> wrote:
> I tried this approach - firebug will pop open every time and I click
> on the X - because I want that window closed - but the functionality
> enabled. The firebug icon turns grey, and disables it.
Sorry I don't understand what you are saying.
> Tell me how I can keep the network monitoring active while keeping the
> network panel closed all the time until I click on the icon to open it
> - ala previous versions?
Use minimize for this [_] icon in the upper right corner.
> >> Even telling firebug to 'enable all panels' and 'on for all pages'
> >> will cause it to not capture net requests when the panel is minimized,
> >Under the settings I expect all net requests to be logged. If you have
> >a case where it fails we will fix it.
> Right now, when repliyng via Google Groups - i have enable all panels
> and on for all pages. I can hit control-n and guess what? the
> firebug icon is greyed out. Sounds like you guys dropped the ball on
> that one.
On Jul 1, 5:47 pm, jjj <jason31...@gmail.com> wrote:
> This even happens with 1.5x.0a07 - I turned it "on for all pages", and
> the checkbox is checked. I'm at the google groups page (http://
> groups.google.com/group/firebug/browse_thread/thread/af951e7538f2dde2?
> hl=en). I even have the net panel open as i typing this, and can hit
> control-n and the firebug icon is disabled.
> Tell me again how that's not broken?
control-n is not a Firebug operation, so I don't know what to expect
if you use that key combo.
Oh, you're right. Here's a test case for you to try:
Open firebug in the webpage of your choosing
Right click and enable 'on for all webpages'
Close firebug by clicking on [x]
Now go to FIREFOX->File->New Window
Result: Firebug is disabled and forgets the 'on for all webpages'
setting.
Perhaps the problem is that the [x] button in the firebug console
window will reset your setting for the checked 'on for all pages'?
On Jul 1, 6:05 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 1, 5:47 pm, jjj <jason31...@gmail.com> wrote:
> > This even happens with 1.5x.0a07 - I turned it "on for all pages", and
> > the checkbox is checked. I'm at the google groups page (http://
> > groups.google.com/group/firebug/browse_thread/thread/af951e7538f2dde2?
> > hl=en). I even have the net panel open as i typing this, and can hit
> > control-n and the firebug icon is disabled.
> > Tell me again how that's not broken?
> control-n is not a Firebug operation, so I don't know what to expect
> if you use that key combo.
Since firebug is an "add-on" for Firefox, this keyboard accelerator is
actually "Ctrl+N" (Or otherwise via File->New Window). Perhaps you're
forgetting that firebug runs in Firefox? Therefore any accelerator
keyboard commands that the add-on "overloads" or "replaces" should be
firebug's responsibility.
Perhaps you should try a simple test-case instead of complaining that
"Ctrl+N" is not part of firebug, and instead try to understand that
its a regression design decision, and with that decision, there is no
affordance in the new version to 1.) match previous firebug UI
behaviors and expecations and 2.) Firefox plugin standards for
enabling/disabling an add on - Perhaps evaluate how the flashblock add-
on functions for a definition of enabled/disabled?
jjj
On Jul 1, 6:05 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 1, 5:47 pm, jjj <jason31...@gmail.com> wrote:
> > This even happens with 1.5x.0a07 - I turned it "on for all pages", and
> > the checkbox is checked. I'm at the google groups page (http://
> > groups.google.com/group/firebug/browse_thread/thread/af951e7538f2dde2?
> > hl=en). I even have the net panel open as i typing this, and can hit
> > control-n and the firebug icon is disabled.
> > Tell me again how that's not broken?
> control-n is not a Firebug operation, so I don't know what to expect
> if you use that key combo.
On Jul 1, 6:41 pm, jjj <jason31...@gmail.com> wrote:
> Sorry, let me rephrase that.
> Since firebug is an "add-on" for Firefox, this keyboard accelerator is
> actually "Ctrl+N" (Or otherwise via File->New Window). Perhaps you're
> forgetting that firebug runs in Firefox? Therefore any accelerator
> keyboard commands that the add-on "overloads" or "replaces" should be
> firebug's responsibility.
To the best of my knowledge Firebug does not overload or replace
control n.
> Perhaps you should try a simple test-case instead of complaining that
> "Ctrl+N" is not part of firebug, and instead try to understand that
> its a regression design decision, and with that decision, there is no
> affordance in the new version to 1.) match previous firebug UI
> behaviors and expecations and 2.) Firefox plugin standards for
> enabling/disabling an add on - Perhaps evaluate how the flashblock add-
> on functions for a definition of enabled/disabled?
Since Firebug did not overload or replace control n in the past or
present I don't now how to help you.
> On Jul 1, 6:41 pm, jjj <jason31...@gmail.com> wrote:
> > Sorry, let me rephrase that.
> > Since firebug is an "add-on" for Firefox, this keyboard accelerator is
> > actually "Ctrl+N" (Or otherwise via File->New Window). Perhaps you're
> > forgetting that firebug runs in Firefox? Therefore any accelerator
> > keyboard commands that the add-on "overloads" or "replaces" should be
> > firebug's responsibility.
> To the best of my knowledge Firebug does not overload or replace
> control n.
> > Perhaps you should try a simple test-case instead of complaining that
> > "Ctrl+N" is not part of firebug, and instead try to understand that
> > its a regression design decision, and with that decision, there is no
> > affordance in the new version to 1.) match previous firebug UI
> > behaviors and expecations and 2.) Firefox plugin standards for
> > enabling/disabling an add on - Perhaps evaluate how the flashblock add-
> > on functions for a definition of enabled/disabled?
> Since Firebug did not overload or replace control n in the past or
> present I don't now how to help you.
On Jul 2, 8:20 am, jjj <jason31...@gmail.com> wrote:
> Then tell me why turning 'on for all pages' causes firebug to fail to
> turn on while browsing in firefox?
I don't know why this does not work for you. It works for me.
> Can you confirm that by turning 'on for all pages', firebug stays on
> for every single page until you explicitly turn it off?
I can confirm that Firebug will stay on for me if I select "on for all
pages" then visit a set of completely different sites.
Here is are the specifics:
1) Open Firefox 3.5 with Firebug 1.5a7.
2) Right click Firebug Icon, select On for all Web Pages.
3) Open www.google.com firebug is up
4) search for "foo" and click on the first result, http://en.wikipedia.org/wiki/Foo; Firebug is up.
5) type http://www.ibm.com into the location bar, hit enter. Firebug
is up
Does this work for you?
Based on my tests and the fact that other users have used this option
successfully, it's my guess that the reason it fails for you is
related to some property of your environment. A simple and effective
test for this is create a new Firefox profile, install Firebug, and
restart.
