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.
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.
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.
Develop more detailed UI mockups.
Implement the in-content page to read the already available data on new add-ons.
I’ve just landed code that allows extensions to include their icon in the add-ons manager view even when disabled. Currently extensions provide their icon by giving a chrome iconURL for us to load. This can only work when the extension is enabled since we don’t register the chrome otherwise. Themes on the other hand provide their icon as a simple file called “icon.png” alongside the install.rdf. Well extensions can do this too now and it will be used in preference to the iconURL but more importantly works at all times (well not before installation yet, but that is at least feasible this way).
We’ll continue to support iconURL for a time to come I imagine, but if you want to keep your icon when users disable you then just put your icon.png alongside the install.rdf (keep the iconURL if you want to work in Firefox 3.5 and lower of course).
This is only in trunk builds right now (today’s Linux nightly has it, tomorrow’s OSX and Windows nightlies will have it). It will be making its way to the Firefox 3.6 nightlies soonish.
As far as mouse types go you tend to find 2 different styles (lets ignore wired mice for now which are the spawn of the devil).
There are notebook mice. These tend to be small, making them uncomfortable for me to use. The big benefit with notebook mice though is that they can come with ultra-small USB dongles, or even better, bluetooth connectivity.
Then there are desktop mice. These are larger, ergonomically designed, with more buttons and all around nicer to use. However the USB dongles you get for them are generally a minimum of an inch long.
My problem is that I use a laptop all the time, I travel with it frequently and I like keeping the same mouse with me that is setup the way I like it. But the notebook mice are too small to use and the dongles with the desktop mice stick out too far which makes them very inconvenient.
What I really want is a desktop sized comfortable mouse that connects over bluetooth (I’d accept a sub-1cm USB dongle but really that just loses me a port). I’ve never found one, do they exist?
I’ll be honest, this post isn’t about Mozilla or even really anything Mozilla related (beyond the fact that it is about a poor web application). However I know that lots of people in the Mozilla community use Dreamhost as their webhost and I figure some of them might want to know to watch out for this and avoid getting into the same mess that I did so I’ll include it in planet feed anyway.
The problem is with Dreamhost’s Web Panel, the service that customers use to administer their web hosting packages. It turns out that certain parts of this panel can’t cope with the idea of you accessing it from multiple tabs or windows at the same time. If you try opening the web hosting settings for more than one domain in different tabs, only the last one you opened will actually work as you expect. Yep, they are remembering, server side, which domain you are editing the settings for.
This wouldn’t normally be the end of the world. I could accept it if there was some error message or it just failed to save the settings for one of the domains it wasn’t expecting. Sadly the panel is not that clever. Instead, no matter which domain’s settings you try to save it always overwrites the domain that was last opened. The panel does subsequently tell you the real domain that it saved the settings for (with a nice green tick to emphasise that everything is fine!) if you are careful enough to read the full message but of course by then the domain’s old settings are gone.
I discovered this when trying to make a change to one of my domains blew away the settings for my secure server, including the ssl keys. Thankfully they were recovered but this sort of thing really shouldn’t happen at all. It seems pretty absurd to me that a modern web application can exist that doesn’t seem to take tabs into account at all.
It’s a shame really because for the most part Dreamhost are the best webhosts I’ve ever used and their panel is very easy to use. Dreamhost’s support team have told me that this is a limitation of the web panel and it should only be used in one window, though there don’t seem to be any warnings about this anywhere. I hate to make sweeping statements like “Surely it would be easy to…” because it bugs me whenever anyone says the same about Firefox, but happily overwriting your settings (and calling it a success) seems like something that should be avoided at all costs.
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.
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.