The new model works for me. The feature of "Navigating from an active page to any page in the same domain also activates that new page" is exactly what I wanted. Thanks.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of johnjbarton Sent: Thursday, May 28, 2009 9:34 AM To: Firebug Subject: Re: Firebug 1.4 Activation Model On May 28, 12:23 am, Nicolas Hatier <[email protected]> wrote: > Well, it it's just for me, I don't mind to continue to locally patch > firebug.js once in a while. Ok let us know when that gets too tedious ;-) > However, I'm pretty sure I'm not the only one who liked the per-domain > side of the previous activation model. "sir_brizz" and Trevan Richins > brought up the same point a few weeks ago in this thread. Yes, but your description of the problem was either clearer or different. As I recall, I thought there cases would be covered by the current solution. > > IMHO having an option to switch from "per-url" to "per-domain" for the > activation model would probably make sense - if I'm able to force a > "per-domain" activation model by modifying 4 lines of code, making that > an option is not likely to be too hard for someone who knows where to > look at. If the activation is per-domain, then every time a user visits a page from a debugged domain Firebug will "suddenly pop up". That means that we need an easy to use UI to control the domain selection and we need the feature to be widely known. That puts us pretty much back in the place we were with 1.3 where people complained about the complexity of the activation solution. In addition I know there are users who want to debug subsections of sites: they want Firebug on for some but not all pages in a domain. How would that be handled? I guess the URLSelector could mark the URI of the domain instead of the page for "shouldCreate" but mark the URI of the page for "shouldNotCreate". That would cause the first use of the debugger on the domain to make all subsequent pages in that domain active, unless the user explicitly closed Firebug on a page. > > NH > > johnjbarton wrote: > > As you can probably tell from reading the URLSelector source, Firebug > > extensions can implement alternative activation schemes. The basic > > idea is to register a TabWatcher listener: > > TabWatcher.addListener(Firebug.URLSelector); > > then implement > > shouldCreateContext(browser, url, userCommands) > > where browser is the Firefox tab, url is the page URL, and > > userCommands is true if the user wanted the page debugged. The first > > call to shouldCreateContext that returns 'true' will cause the page to > > be debugged. > > > Honza has a tutorial on putting together an extension: > >http://www.softwareishard.com/blog/firebug-tutorial/extending-firebug... > > > Currently there is no simple way to attach a listener without > > implementing a Firebug module. We could add this if you would use it. > > > jjb > > > On May 26, 6:38 pm, Nicolas Hatier <[email protected]> wrote: > > >> I think the new model makes sense, except for one thing - we need to be > >> able to enable it (and keep it enabled) on a per-domain basis. > > >> Most people debug websites with Firebug. But while I debug websites, I > >> (and several other people as it seems) also pages on specialized systems > >> whose URL may contain a session id (webmail, for instance) > >> -http://example.com/Session/jo48j7svo8467shsjeo4f76se46/webmail.html > > >> For us, it doesn't make sense for firebug to remember it is enabled on a > >> per-page basis, as the page URL changes each time we open a new session > >> on our system. > > >> For now, I'm able to use the latest firebug alpha by applying a small > >> patch to firebug.js each time a new version is released, basically > >> adding getDomain at three or four places into the URLSelector functions. > >> But it would be great not having to do this, even if it's a hidden > >> feature accessible only using about:config... > > >> Regards > >> NH > > >> Jan Odvarko wrote: > > >>> I have written a post about the Firebug 1.4 activation model. > >>>http://www.softwareishard.com/blog/firebug/how-to-enable-and-disable-... > > >>> The post explains the logic of the current implementation. If > >>> something isn't clear or doesn't work as described, please let us > >>> know, or file a new bug > >>>http://code.google.com/p/fbug/issues/list > > >>> Thanks! > >>> Honza --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/firebug?hl=en -~----------~----~----~----~------~----~------~--~---
