Firebug Feature? Tagged ‘firebugged’
For Firebug 1.4 we want to try yet again to improve the enabled-panels user experience. The 1.2/1.3 solution is too complex for users and too hard for us to maintain.
One idea is to turn on the resource-hungry features only for web pages that Firebug is open on. If you are debugging, you have your site selected and you have Firebug on. If you wander off an read your email, you don’t have Firebug up. Firebug would be on when you are debugging and off when not. Makes a lot of sense (even if it is not as easy to implement as it sounds).
Part of implementing this is to remember what pages you had Firebug open on. And one way to implement this remembering thing is the Firefox Places tagging API. By tagging pages as “firebugged” when you open Firebug on them, we can check this tag when you open that URL later. Maybe you don’t like us to mess with your tags, I don’t know. As part of the trade off, you can type ‘firebugged’ in to the location bar and get a list of all pages you use Firebug on:
That seems pretty cool to me. (Note that the top link here is a page I opened Firebug, then closed it, seems like Firefox is confused).
Still investigating this idea, comments welcome.
jjb
February 4th, 2009 at 1:51 am
You could also try using content prefs:
https://developer.mozilla.org/En/Using_content_preferences
February 4th, 2009 at 1:59 am
I like this idea, but then I don’t use tags heavily.
February 4th, 2009 at 2:52 am
I’m not sure I like the idea of messing with my tags. While it’s just Firebug it’s not too bad, but what if other extensions decide to do the same?
From the docs, it sounds to me like the Places Annotation Service might be a better approach which achieves a similar result:
https://developer.mozilla.org/en/Using_the_Places_annotation_service
February 4th, 2009 at 3:15 am
I have another suggestion. What if we enable only when FB panel / window is open ? So if you want to do some resource hungry operation open firebug panel. Here you don’t have to remember urls
February 4th, 2009 at 4:02 am
hmm.. I’m sure there is a better solution to achieve this.
The tagging system is designed for user’s bookmarks, using it for Firebug’s internal logic seems kinda messy.
February 4th, 2009 at 4:32 am
Doesn’t Firebug already remember which pages it’s open on, in order to show itself when a tab is selected (and list the active pages in the status bar tooltip)?
February 4th, 2009 at 7:14 am
I like the idea of having something visualized on the address bar, but messing with users tag doesn’t seem good to me. Having an icon next to the star, in gray or coloured, as the guys of “read it later” do (https://addons.mozilla.org/en-US/firefox/addon/7661) would be effective
February 4th, 2009 at 8:29 am
This wouldn’t really be useful to anyone who predominantly uses delicious or Google bookmarks instead of Places. While somewhat unrelated to this post, what about plans on including some sort of wildcard functionality to enable FB for a number of sites i.e. those who do their local dev work at my_domain.dev, my_second_domain.dev, etc
http://code.google.com/p/fbug/issues/detail?id=431&can=5
February 4th, 2009 at 8:33 am
it’s an interesting idea but I agree with M.T and MarkC that we shouldn’t be messing with people’s metadata.
There’s no reason we can’t create our own database for storing this type of data via the MozStorage APIs. It could also be useful for storing net panel data, breakpoints, etc.
see: https://developer.mozilla.org/En/Storage for an introduction on how to create databases.
February 4th, 2009 at 8:49 am
M.T, that is a good point, messing with user tags (by toggling a firebugged tag) in principle is a bad idea. Even so it might be the best solution for us. Personally Firebug can toggle tags all day if it makes my live easier. I invited firebug into my house and I want it to do what it need to do to help me.
I am a poster child for not grokking the current system. I probably never read the instructions
. I find myself asking “does this effect this page or this domain or this Tab (wherever I navigate to) or this entire firefox session”, “I disabled firebug, yet it comes back on the next session”, “did it really enable it for all those pages that show up in the tooltip?”
1 side point: I understand the concept of 2 classes of “on” for lightweight and heavyweight features. That’s great. I don’t want the option of disabling the lightweight features, I want them always on if firebug is on. And I don’t want the granularity of picking from the heavyweight feature, to much to think about. I just want on/off for all of them.
Firebug is wonderful, thanks.
February 4th, 2009 at 9:18 am
Personally, I was happy enough with the old approach; Firebug was either on or off completely, or you could select specific sites to turn it on for. Do we really need the complexity of per-panel settings?
February 4th, 2009 at 10:46 am
I use Firebug…but I don’t use bookmarks.
I stopped using bookmarks many years ago, and strictly use the Awesomebar to get where I’m trying to go. (Before it’s existence, I used to just type URL fragments…now life is easier.)
I’d second the recommendation of using content-specific prefs – that’s kind of what they were designed for, and are far less intrusive.
February 4th, 2009 at 10:47 am
P.S. Make that ‘site-specific’ prefs.
(e.g. browser.zoom.siteSpecific)
February 4th, 2009 at 12:08 pm
John Silvestri: Thanks for the suggestion, but content preferences are per-site. Firebug users want per-page control because they work on different pages of the same site.
February 4th, 2009 at 12:11 pm
MarkC: The annotation service is not similar: you can’t find the annotations for a page using the Firefox UI as far as I can tell. But I don’t think that automatic metadata is a bad thing.
February 4th, 2009 at 12:12 pm
Actually tagging is per URI, its not connected to bookmarks. However the Firefox UI seems to only allow you to tag bookmarks.
February 4th, 2009 at 12:59 pm
Jigar Shah: that is the proposal. But users want the settings to persist across sessions. So we have to remember.
February 4th, 2009 at 4:13 pm
I’m a very big fan of Firebug. Beside Firebug I’m also a big user of Foxmarks.
And now comes the problem, every time I change a tag, Foxmarks registers this and what to synchronize. So every time I open Firebug you put a new tag there and Foxmarks gets busy.
I see this as a big disadvantage, which leads to a lot off busy servers at Foxmarks.
I vote for another solution.
February 4th, 2009 at 4:31 pm
jerone: Thanks, this is the kind of information I was looking for: a concrete example of a problem that automatic tagging will create for a user.
Right now I am leaning towards using a plain text file to store the Firebug history info. That would be the easiest to debug and maintain.
jjb
February 5th, 2009 at 2:58 am
I know that there’s no UI to access annotations in Firefox, but I’m not sure how many people will really need that facility anyway. It wouldn’t be hard to add a view to Firebug itself to display the list of “Firebugged” pages if that’s really an issue. I had presumed that there would still be a “Disable Firebug on this site” option in Firebug itself for removing the annotation.
Annotations can take an expiry period (albeit not very granular). I could see this being used so that pages automatically get un-Firebugged if they’re not accessed for some time, while the annotations on frequently accessed pages get refreshed every time Firebug is opened on the page. This would mean that if someone enables Firebug on a site just once to have a prod around and see how it’s built, they won’t suffer a performance penalty forever if they forget to untag it.
I think the biggest issue with using tags is that it opens the floodgates for other extensions to do the same. It’s a bad precedent to set – I don’t want to find that my own tags ever become lost in a sea of extension-created tags.
February 5th, 2009 at 9:13 am
MarkC: Since annotations don’t have a UI I think they are not a viable option. It’s not only about the annotations being invisible to users. They are also invisible to us. So we can’t check that we are successful and we don’t have tools for resolving problems with them. Moreover if Firefox does not use annotations they are effectively orphaned code. We have enough of that from jsd already.
A viable alternative is a plain text file with one URL per line. That’s probably what we will do.
February 5th, 2009 at 10:06 am
Surely you can check you are successful by simply trying to read the annotation back again, using the annotation APIs. I suspect (but haven’t checked) that they would also be visible if you access the Places DB using normal SQLite tools. As for them being orphaned code, they were only introduced with Firefox 3 so I’m not sure they’ve even had a chance to get as far as being orphaned.
I don’t have any vested interest in Annotations, so if a text file is a better solution, then so be it. They just seemed like a more “correct” way to attach metadata to the Places DB than by overloading the Tags mechanism to me.
February 5th, 2009 at 4:40 pm
I haven’t read the other comments, but I like the idea of being able to type “firebugged” in my address bar. Keep up the great work John!
February 7th, 2009 at 1:42 am
Wouldn’t SQLite be faster than a plain text file? At least with SQLite the URLs could be indexed.
February 16th, 2009 at 6:26 pm
Glen: a plain text file would be much faster because it only has to be read once at the first use of Firebug and written once at shutdown. The URL list could be a Javascript array chopped at 200 characters by 100 entries. The SQLite has do a look up for every new page and a write for every page Firebug is opened or closed on. I assume every write to the DB makes a disk access, though its possibly done asynchronous with the user task. Since the time for disk access dominates, the plain text version would win.
But that only considers run time. We also don’t want to invest development resources in things that don’t make a difference. So far the annotation solution is working, so I’ll leave it for now.
February 18th, 2009 at 1:30 am
A little, perhaps offtopic, proposal for changing the user experience. Personally, I think the users problem is in the difference between a global enable/disable, and a per-site enable/disable. I do not know if there are two ‘camps’, one that always wants Firebug turned on or off, and another that wants the per-site settings. But you pointed out that performance is unacceptable when turning Firebug panels on permanently.
So, my proposal is: remove the global enable/disable switch. This would clear up the dropdown in Firebugs tabs – you might get away with removing the dropdown fully, and replace it with a permanent ‘enabled for this site’ checkbox which is much more discoverable.
This would also clean the site list: it would become a whitelist, no need to add disabled sites when there’s no global enable.
I know this is a change that will remove behavior some people might rely on, but I believe its for the better. Love to hear comments!