We’re always trying to stay in touch with the add-ons community and the issues facing add-on developers, and one of the most common ways of letting us know pain points is by filing a bug in Bugzilla. We track almost everything here — from actual site bugs and feature requests to tasks and administrative issues.
addons.mozilla.org (AMO) is a huge site, and it’s quite possible you’ve found a minor glitch or more serious bug that we haven’t heard about yet.
Bugzilla can be complicated to a new user, so here’s a step-by-step guide to letting us know about a problem with AMO:
- Create a Bugzilla account. (NOTE: If you’re a longstanding Mozilla community member, you may already have one. Check first to make sure you aren’t already logged in when you visit the site.)
- Search for existing bugs. Looking for an existing bug is helpful to both you and us, because you’ll see any progress that’s been made in resolving your issue, and we won’t have to close your bug as a duplicate.
- File the bug. Select the best component, enter a brief summary, and describe the problem you’re having.
That’s it! Your new bug will be emailed to everyone that is interested in AMO development, and we’ll triage the bug and help sort it out.
Happy bug filing!
There’s been a lot recent discussion on Bugzilla’s UI. I figured I’d share some work I started last month on a new non-default skin for bugzilla.mozilla.org. I, along with a few alpha testers, have been using it via userContent.css, and I’m really loving it. It has a lot of things I consider to be improvements, although there’s only so much you can do with pure-CSS skins.
I’m working on bugfixes and tweaks still, but am hoping to have it ready for general use soon.
Someone asked me how I was searching Bugzilla from my location bar last week, so I figured there are probably a few others who aren’t familiar with QuickSearch + SearchWords and would benefit greatly from finding out about it, so here’s a post!
The little search box on every page of Bugzilla is useful for more than just typing in bug numbers – it actually has a pretty detailed syntax that can be used to narrow down bug queries faster than using advanced search in many cases. Jesse has a page listing all of the tricks, but I’ll mention a few of the ones I use.
Using a colon in QuickSearch specifies the product or component to search in. For example, :firefox would search bugs in the Firefox product and :mozilla.org searches mozilla.org, addons.mozilla.org, and a number of components in Websites.
QuickSearch defaults to searching only open bugs, but adding “ALL” as the first word of your search will make it search both open and closed bugs. @ will search for bugs assigned to that user. So, “ALL :addons @fligtar” returns all bugs I’ve fixed or am currently assigned to in addons.mozilla.org product.
QuickSearch is great in itself, but combined with SearchWords, it’s even better. (SearchWords is part of Firefox 3, so you only need to install it in Firefox 2.) I have the “bug” keyword associated with the Bugzilla@Mozilla search engine, so typing in “bug :cvs” in the location bar will return all of the open CVS Account requests.
I never bookmark bugs because of this method, even if it means once a day doing Command + T, Command + L, “bug :addons statistics” to find the same bug over and over.