In the process of switching from CVS to Mercurial (and behind the scenes Tinderbox to Buildbot), quite a lot of Mozilla’s build and release systems have had to be updated. Sadly one of the casualties that has yet to be resuscitated are nightly builds of XULRunner on the 1.9.1 branch and trunk. Catlee is now doing some excellent work to get these up and running, but until that gets going here are some semi-official builds using the code matching Firefox 3.1b3. I say semi-official, they were built on regular build slaves using the standard configuration, but just done by hand. I also haven’t tested all of them yet so let me know if you hit any issues, they might be good indicators of issues we’ll see with the nightlies.
Tag: development
Testing the background update checks
Firefox does a fair number of things in the background to help keep things up to date. This includes checking for updates to Firefox itself, checking for updates to add-ons you have installed and checking for updates to a blocklist that disables known unstable add-ons. Normally it does these things quite happily, but for developers and QA, trying to verify that these background tasks are doing what they are supposed to can be annoying. After all who wants to leave Firefox running for a day just to see if it finds a new update?
I’ve written a small extension that helps test these background tasks. It is fairly simple, just gives you a menu option to trigger one of the background checks. It saves delving through preferences and changing the timers to run faster. Most users shouldn’t use it but I figure it is useful for other developers and add-on authors so I’ve put it in the sandbox on AMO and you can go download it from there.
Brussels bound
This weekend is FOSDEM 2009 and I’m actually managing to attend this year. It’s kind of weird, I keep doing all this travelling to the states yet I end up having to miss all the awesome stuff that goes on in Europe for various reasons (often because I am all travelled out from the states). But I’m going to be at FOSDEM even if it kills me, which considering the snow on the roads and serious travelling I have over the next few months is a possibility. Thankfully the jetlag from Europe is a lot easier to recover from.
I’m not giving any presentations however if you want to grab me to talk about extension development, XULRunner applications or anything else then feel free. Hopefully the lack of beard won’t leave me too unrecognisable.
Updated Interface lists
I’ve generated a new database for my interface listing webapp so you can now see the current state of the 1.9.1b3pre and 1.9.2a1pre platforms. So for all you extension developers getting ready for the Firefox 3.1b3 release maybe you want to see what has changed since 3.1b2? Or since 3.0?
There are still more things I want to do with this web-app, but right now my time is being spent elsewhere so for now I’ll just keep it up to date with the beta releases. Once 3.1 final is released I’ll likely remove all the beta versions since they probably won’t be necessary then.
I have for the time being had to disable caching in the application, it was eating up literally gigabytes of disk space on my web server and not giving all that much of a speed-up.
Zooming along, hopefully as fast as before
I’ve just landed a fix to a bug that has irritated me ever since page zoom started getting remembered for sites. It fixes a real problem you find if you both use zoom a fair bit, and load pages in background tabs. When you finally decide to look at that tab there is this little pause (or long pause if the page is large) and sometimes a visual jump as it re-zooms the content. It also changes where the page is scrolled to which is very irritating if you have just clicked a link to a specific line in some source code for example.
The fix was relatively simple, the problem is it causes a little extra time to be spent loading background tabs. About 3ms from the numbers I have. Normally this is small enough that you wouldn’t notice in comparison to how long a page takes to load. One concern though is how this impacts session restore where you have a lot of background tabs all trying to load at once. The tests I’ve run say pretty much what I’d expect, Firefox opens, all your previous tabs are displayed and start loading with no change due to this fix, the reason being that the additional time is spent later in the load cycle of the tabs.
Of course tests never quite mirror reality so I’d like all you nightly testers to keep an eye out to see if you notice a sudden change in the performance of the browser when you open it and session restore has a lot of tabs to restore. Obviously before filing a bug do the good thing and try it a few times both with nightlies with the fix (tomorrow’s should be the first) and nightlies without. If you do see definite issues then file a bug and CC me. Assuming there are no issues then I’ll be trying to get approval to land this for Firefox 3.1 in the near future.
What is the most useful way to present interface lists?
I’ve just rolled out a small update to the interface cross reference, nothing major, just fixing a few bugs and I’ve put up what looks like the final set of interfaces for 1.9.1b2.
I’ve now figured out the best way to gather the interface lists and so the cross reference now includes all interfaces used in all 3 major platforms of Firefox. It is relatively simple for me to add the interfaces for other applications now but this got me thinking about what kind of uses people are making of this and how the multi-OS, multi-app interfaces should be presented. A few ideas came to mind:
- App developers probably just want to see the interfaces in their app, either only those that appear for all operating systems or those for a specific OS in some cases.
- Add-on developers probably want to see some kind of shared set of interfaces (what you might call gecko/toolkit) that appear for all apps they are targeting, unfortunately this changes depending on the set of apps. Again they probably want for all OS or for a specific OS.
- Maybe I shouldn’t even bother doing anything and just include a note in the interface display about where the interface actually exists.
I’m sure other people have other ideas of how it might work, any suggestions?
Improving the API references
I forgot to add to my last post some information about what I currently had in mind to improve about the API reference I’ve been working on. Any further suggestions people have are very welcome, but here is the current few ideas I have.
Currently it only indexes Firefox and Gecko interfaces, in fact it only indexes those used by an OSX build of Firefox. It would be nice to be able to index interfaces for all the main applications and for all the platforms. There are a couple of issues with this. Firstly I’d want the UI to work so people viewing it could select what set of interfaces they wanted to see. Secondly actually building the lists of interfaces for each application and OS is going to be pretty tricky I think. So far I’ve resorted to building Firefox then looking in dist/idl. This works but it is time consuming. Possibly I might be able to come up with some clever nonsense to make the build system only compile idls but we’ll see.
It would be nice to be able to include a list of the component contract ids available in the platform and what interfaces they implement. This is I think pretty difficult to do just by parsing the source files. Potentially a little extension could run in the app and do some looking through Components.classes to find this out. One issue here though is there is no way to tell whether components are services or not so instantiating them is potentially problematic. This is a problem that could be solved by brute force, or maybe doing a special instrumented build.
So those are my main two ideas, if anyone has any suggestions on how to make those tasks easier or for other things that should be there then shout them out.
API reference updates
Since my first announcement about my little api reference tool I’ve slowly been working on updates to make it more useful and easier to navigate around. I’ve now gone and pushed the latest version live. A few of the new features:
- The main and platform lists of interfaces are split by the module where the interface lives.
- Interface lists have a quick filter box, type in it to filter the list quickly.
- Any interfaces used as return types or parameters are now links to get you straight to the information about them.
- Full IDL support so it now lists all the special attributes and for the uninitiated they have tooltips that explain what they mean.
- You can now list all usage of an interface by other interfaces.
- Constants are ordered the same as in the source IDL since they tend to make more sense that way.
- Includes direct links to the source IDL file.
I’ve also updated the database with the latest APIs in 1.9.1b2pre and as soon as 1.9.1b2 is frozen I’ll update it again just to be sure it has the latest versions.
You can also search the API for interfaces. There isn’t any UI for this right now but it is perfectly set up for a smart bookmark. Just use http://www.oxymoronical.com/experiments/apidocs/search/interface/%s for the url and an appropriate keyword and you can do quick searches for substrings of the interface name.
Planning for the future
For some time now I’ve been throwing around ideas for new features that we may want for the add-ons manager. After lots of thought and trying to take on board comments from anyone that would pipe up I decided it was high time to put together an actual plan for what features I have decided should be pursued and what order to start tackling them.
The roadmap itself should be pretty self explanatory, just remember that nothing is ever set in stone. I’ll try to keep it updated as things change, features seem less important or new items are added. But for now this is how I see the add-ons manager evolving over the course of about the next year or so, which may be the next two versions after Firefox 3.1.
Obviously the ordering of the goals may not be quite to everyone’s taste, but I’ve tried to strike a balance between getting new features done and getting groundwork laid to make things better in the future. I’m happy to take any comments people might have into consideration for altering the plan, but chances are I won’t be making any big changes unless you have some pretty damning evidence that a change is necessary 🙂
Finding API Changes
I started a small discussion on the newsgroups the other day wondering about the numbers of API changes that had landed on trunk since 1.9.0. It was a short discussion, maybe partly because all I had to go on were the vague metrics that mercurial could give me. It also evolved a little into a discussion of how add-on developers we’re meant to find out about API changes. It’s true that as developers we are getting better at trying to announce our changes as much as possible, but inevitably we miss some, and if you don’t track the announcements what then?
Yesterday on IRC ted jokingly made the comment that I could use the idl parser than bsmedberg wrote in python a short time ago to find out more about the API changes. I’ve been hard pressed on other work lately so it wasn’t long before the prospect of knocking together a little side project had me too interested to do anything else. In a short space of time I had something that could parse all the in-tree idl files into a sqlite database that I could then query. It wasn’t long after that that I got a small web app written to display the content of the database, but I spent some more time today getting it a bit more useful before I showed it to the rest of the world.
So here it is, the API viewer. You can look at any interface in any of the platform versions that I’ve bothered to scan. And here is the more interesting bit, you can compare two platforms to see what interfaces changed. Not happy there? Well you can also compare an interface in different platform versions in a sort of diff like display.
I should note that it is only indexing the core and Firefox interfaces for now, and it’s close to indexing all of the idl files from the sources, many of which don’t make it into the final build (which makes life interesting as it turns out some of them are invalid xpidl!). So you can’t trust that interfaces you find are necessarily useful etc.
The web app is really a prototype right now. Navigation is probably a bit clunky and it’ll need more work to be really useful but I wondered what other people thought of it. So what do you think? Is it useful? What other interesting information might we be able to grab automatically like this?
Update: I’ve added details of the current trunk, 1.9.1b2pre as of today so you can see what changes are coming since the last beta. Not sure how often I’ll keep that up to date though.