As part of the ongoing work to bring basic support for lightweight themes (based on the ideas from the Personas extension) into Firefox 3.6 I’ve today landed the main UI parts that allow users to see and select between lightweight themes they have used recently. Dão landed most of the backend last week but we’re still waiting on the support for installing new lightweight themes before this feature will be truly usable in the development builds. For the time being here is a shot of what the UI looks like in the add-ons manager after you have used some lightweight themes.
The idea is that users will install lightweight themes from websites. The add-ons manager will include the most recent lightweight themes used to allow the user to use them again. For this release they are offered as a straight alternative instead of other installed themes. We’re going to replace the default icon there with something more themey.
I have been remiss in not posting a status update about this in two weeks, but that is mostly because we have unfortunately had to slow down work on this feature. The problem is that a string freeze became necessary for all toolkit code (the code shared with the Firefox mobile browser and where this feature would have lived). Unfortunately this all came up over a small period when I was travelling long distances and having to take time out to satisfy immigration authorities that I wasn’t a terrorist intent on bringing down the U.S. government.
In the end there just wasn’t enough time to finalise the UI and be confident that it was correct before the freeze. This means that this feature isn’t going to make Firefox 3.6, however the intention is to continue working on it to get it into Firefox 3.7. It will just be on hold for a short time since I need to devote myself to Firefox 3.6 blockers.
This week has been the Firefox work week where almost all of the team, including me, made our way to Mountain View. This pretty much means that you spend the entire week in meetings since when you’re remote it can be hard to keep in sync on everything. Of course this means that the amount of coding is pretty low for the week so there isn’t a great deal of progress to report here.
Status
This week, Alex and I met to come up with a rough design for what this is going to look like now that we know that the doorhanger notifications we were hoping for aren’t going to make Firefox 3.6.
This is a weekly status update on the feature to notify users about add-ons that third-party installers have added to Firefox. You can read more about it in last weeks blog post or on the project wiki.
Status
There has been little progress this week mostly due to waiting to see whether the doorhanger notifications UI was going to arrive in time for Firefox 3.6. It looks like it isn’t so instead we are discussing using an in-content page to describe the add-ons that have been installed and allowing users to disable them.
Regular readers of my blog will probably spot that this is very similar to an idea I had a couple of months ago. What we’ll probably try to do is integrate both new third-party add-ons and new add-ons installed by the user into the same in-content page. It’s possible that we won’t be able to go the full stretch and allow add-ons to add their own content into this page in the first pass, that will depend on time constraints. I think that even without that this is still a very worthwhile feature.
Next steps
Develop more detailed UI mockups.
Implement the in-content page to read the already available data on new add-ons.
You may have noticed many of the Firefox team starting to blog progress reports on Fridays. This is a part of our new plan to clearly define the main projects we are all working on and communicate a much as possible about them rather than just having users surprised to see them turn up in nightlies. So here is my report for this week:
I’ve been working on improving the level of information and control we give users over add-ons installed by other applications on the system (think Skype, Java, AV tools etc.). The work for this is being tracked in bug 476430 and on the project wiki.
The basic problem is that sometimes when another application installs an extension into Firefox the user either isn’t told so by the application, or more likely the information is missed in installer pages that users click straight through. It is then a surprise when users later find this thing in the add-ons manager, sometimes when it is causing problems. The goal is to make sure that this never happens by telling users that something has been installed and giving them the option not to use it.
We considered a couple of principles for the design here:
Firstly we should not delay starting Firefox. If we present UI asking a question before startup then users will just click through it.
Secondly we shouldn’t just run Firefox with the new extensions enabled, users should be given the option whether to use them before they are run for the first time.
Thirdly the eventual result of a user taking no additional action should be that the new extensions should be enabled. If we default to disabling these items then the majority of users will never enable them. This would make other applications stop using these mechanisms to integrate with Firefox and seek out more hacky, less controllable ways to do it, something that no-one wins from really.
The resultant plan is a hybrid approach. The first time Firefox runs after a new extension is detected it will not enable it. Firefox will tell the user what has been installed and tell them that the extension will be enabled the next time Firefox restarts. The user can then choose to disable it permanently (or at least until they choose to re-enable it in the extension manager). The user will probably also be presented with a quick way to restart Firefox to use the new extension.
Status
The backend code that disables detected extensions during the first run is complete, as is the frontend code that marks them to be enabled after a restart. The UI still needs to be connected but that will require the doorhanger notification API to be completed.
Thanks to the hard work of Nick Thomas and Lukas Blakk, today I can announce the availability of two new official releases of the XULRunner runtime and SDKs. XULRunner 1.9.0.12 is a maintenance release for the 1.9.0 branch (the code that matches Firefox 3.0.x). XULRunner 1.9.1 is the first official release of XULRunner on the 1.9.1 branch (which matches the code in Firefox 3.5.x). Unfortunately we’re not quite at the point of shipping XULRunner releases at the same time as Firefox 3.5.x releases, but we should have a 1.9.1.1 release soon.
A question I have been hearing quite a bit on IRC since Firefox 3.5 was released. We don’t quite have the build automation set up to do XULRunner 1.9.1 releases at the same time as Firefox yet, but Nick has been awesome and manually spun some release candidates. These should be pretty much good to go but it would be useful if anyone interested could try them out and report on any serious problems they see. Either just comment here or file a bug and mark it blocking bug 502915.
While many of you were out blowing things up over the weekend I spent a few days varying between getting quite a bit done and banging my head against my desk in frustration.
First I updated the XPCOM interface lists that I have been working on with the final release version of Gecko 1.9.0. A few people had asked me for it but I had hit upon the problem that I had lost some of the arcane scripts that I was using to gather the data and so I had to rebuild them first. I have dropped information about the beta versions of 1.9.1 now, just because it was less work that way, if people desperately want them back then I can probably do it.
Secondly I finally sat down and put some hard graft into my rewrite of the project. Some time ago I decided on what extra information I could easily find out automatically and wrote the new code to shove it all into a database. It took till this weekend for me to actually write the web front-end to it. Despite appearances it is actually a complete rewrite. Previously I was using hand-rolled database access code in php. The new version is based on Django which is apparently what all the cool kids are using these days. I was for the most part pleasantly surprised by Django, it makes quite a lot of things significantly easier, but it does suffer from the problem that most object mappers do, it never quite does exactly what you want (or expect). Still I’ve no doubt despite the teething problems I found I have got further like this than I would have by hand. Pro-tip to those thinking of using it, don’t trust it to be right when it tells you what line of a template is causing an error.
Not everything is implemented yet, and I’m sure there are a few bugs laying around to find, but you can take a sneak peek at it. This is what is new:
Lists components as well as interfaces
Shows what operating systems interfaces are available on (watch out, this can and does vary with the version of Firefox)
Shows what components implement a particular interface (again, can and does change with the Firefox version)
Shows what interfaces a component implements and for which platform (ditto, our platform is complicated ok?)
There is actually a lot more potential information that could go into the database, including listing for multiple applications, but I think the UI will probably not develop that much further, the additional information would just make things far to complicated to understand.
This is mainly of interest to add-on and application developers and I should stress from the outset that this is talking about changes in Gecko 1.9.2 which will first be released in whatever version of Firefox comes in 6-12 months time. Firefox 3.5 is unaffected by this change.
What was it?
Contents.rdf was the old way of performing chrome registration for add-ons. It was replaced by chrome.manifest back in the mists of time in Gecko 1.8 and Firefox 1.5 (back in 2005 as it happens). We’ve continued to support reading contents.rdf for those developers who hadn’t had the chance to make the switch but after 4 years it seems time to remove that support and clean up the code that dealt with it.
What does this mean?
Chances are not a lot. If you are an add-on developer then look in your add-on’s source code. Is there a chrome.manifest file there? If so then you don’t need to do anything, you are already using the modern method of chrome registration. If not then look for contents.rdf files. If you don’t have any then you just have an odd add-on with no chrome.
How do I cope?
If your add-on actually doesn’t have a chrome.manifest file and needs one then you need to do one of two things. One option is simply to read the documentation on chrome.manifest and learn how to replicate what you have in the contents.rdf files into the manifest. Another is to install your add-on into a toolkit application since Gecko 1.8. You’ll find that when it installs it it also creates a chrome.manifest file for you from your contents.rdf files. Just copy it.
If you really need to support both an old version of an application (before Gecko 1.8, or not toolkit based) and a new version (Gecko 1.9.2 or newer) then you will need to keep both contents.rdf and chrome.manifest, replicating the information across the two.
When does this happen?
I have just landed the patch that removed support so trunk nightlies from tomorrow (12th June) should be affected.
Add-on developers face a bit of a challenge when it comes to helping users get the most out of their add-ons. Even once you are past the first hurdle and have got a user to install the add-on, you then need to help them get up and running quickly after Firefox has restarted. Presented with just the blank Firefox window it can be difficult for a user to know where to go next. Many add-on developers have taken to including a first-run experience to give the user some help. Display a webpage with some instructions or open a wizard to start setting up. As this practice started it was generally acceptable. Few add-ons actually did anything so it was helpful. These days though many add-ons are doing it, no doubt with more to come. It is starting to be an annoyance in some cases. Others have already been discussing ways that we can improve this.
In Firefox 3.0 we introduced a small feature to try to alleviate a little of this. After restarting Firefox the user would be shown new add-ons that had been installed so they could configure them. It also provided a little consistency across the restart which was normally done from the add-ons manager.
The current post-install display
This UI had the additional small benefit that it would also display when other applications installed extensions into Firefox without the user’s knowledge. However as a post-install experience it really hasn’t worked out all that well for a few reasons:
It’s invasive. It pops up in front of the user after the restart and they feel the need to close it before doing anything else. This makes it almost as bad as some of the first run experiences provided by extensions.
It’s confusing. It can be pretty difficult to identify just what add-ons have been installed especially when the list is long.
It provides no next steps. Although if you click on the new add-ons you might get a chance to configure it, it doesn’t actually help push the user in any direction.
We’ve been thinking about ways to improve this for a while and there are a few different ideas floating around. I’d like to float one of them here and see what people think. The goal is both to let users know that new add-ons have been installed and let the add-on help the user move forward without needing to show popup dialogs or inundate the user with a webpage per add-on. It also needs to work in applications that aren’t Firefox. Excuse the poor mock-up, my UI skills aren’t all that hot.
Proposed first run experience
The idea is that in Firefox this would display in the webpage content area. It might display immediately after startup, or it might be better to use an alert to tell the user new add-ons are there and then display it when they click on the alert. Other applications can open this in a new window or wherever they wish.
It’s designed to be clear exactly what has been installed and give the user things to do with those items. Preferences at a bare minimum, but the yellow highlighted areas are the interesting bit. Those represent overlay points where the add-on can put whatever UI it likes. This might be a simple message to tell the user how to get started. It might be a few of the most common settings, maybe a login box. It might be a button to launch further UI like a wizard.
I think, even if this were to open immediately in Firefox, this addresses the main deficiencies of what we currently do. I’d hope that many add-on developers could then stop their custom first-run stuff and instead just use this, but I know there are lots of different needs out there so I’d like to hear where this doesn’t work to see if we can accommodate.
