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.
Next steps
- Finalise the UI
- Wait for doorhanger notifications to be implement
- Wire up the detection code to the UI
- Figure out whether we can test the UI
What if an extension is actually distributed standalone as an EXE and installed that way?
Will Firefox still warn about it?
Even though it was designed to be installed this way?
Fundamentally right now Firefox can’t really tell whether an external extension was installed as part of another application or standalone, so the UI we add here will apply to both. I have to be honest though, I’ve not come across standalone extensions shipped as an exe, can you name some examples?
Really I don’t want to think of this new UI as a warning. The vast majority of cases where system extensions appear are legitimate, we’re just allowing users to control whether they ever run without significantly delaying startup.
Actually Brand Thunder has started shipping some extensions as EXEs.
It allows distribution on sites that don’t accept XPIs.
For example:
http://www.softpedia.com/progDownload/Indianapolis-Colts-Boom-Download-135626.html
Basically they are investigating distribution mechanisms other than AMO.
Yes..I am troubled with one extension mugshot that comes default with Fedora. Its painful.