Mossop Status Update: 2010-01-29

Done:
Intermittent test failure tracking
Post mortems
Wrote a patch to fix showing incompatible add-ons to users who have upgraded
Started setting up a project branch for the add-ons manager work

Done:

  • Intermittent test failure tracking
  • Post mortems
  • Wrote a patch to fix showing incompatible add-ons to users who have upgraded
  • Started setting up a project branch for the add-ons manager work

Next:

Need to change my working practices and start ignoring new emails unless they are critical so I can actually get more work done.

Broken executables in extensions in Firefox 3.6

If you are an extension developer and include executable files in your XPI package (binary or shell scripts) then you may be seeing problems in Firefox 3.6.

Back between Firefox 3.6 beta and Firefox 3.6 RC we took a small fix to the extension manager that changed how we extract the files from the XPI package. The fix involved adjusting how we accessed files to avoid hitting problems with certain anti-virus tools that would occasionally lock files in the middle of extraction making us fail to install the add-on. A side effect to this fix leaves us setting file permissions on the extracted files in a slightly different way to previously. This side effect means that the executable permission is getting stripped from all extracted files. If you try to execute these files with nsIProcess it will likely fail.

There is a bug on file and I have a patch almost complete so hopefully this should be fixed in Firefox 3.6.1 but until then you can workaround this in your extension by setting the executable permissions on the file yourself. Assuming you have a file variable that is an nsIFile pointed at the executable, just do:

file.permissions = 0755;

In case you were wondering why we enforce file permissions at all, it is because it turns out there are quite a lot of different zip tools that developers use to build add-ons. Some of them are unfortunately broken and embed bogus permissions into the generated XPI. After extraction it leaves us with files that are unreadable/unwritable which makes the add-on fail to work correctly. This most commonly affects developers on windows (where permissions are a little laxer in general) who get odd bug reports from users on Linux which is respectfully refusing to use the files. The easy fix is to enforce read/write permissions on the extracted file in the first place.

Mossop Status Update: 2010-01-22

Done:
Identified and mostly fixed a regression in 3.6 involving executable files in XPI packages.
Worked with AMO to try to improve the capabilities of release notes for add-ons.
Figured out how to make the backend parts…

Done:

  • Identified and mostly fixed a regression in 3.6 involving executable files in XPI packages.
  • Worked with AMO to try to improve the capabilities of release notes for add-ons.
  • Figured out how to make the backend parts of lightweight themes and xpi themes operate independently.

Next:

  • Implement the new add-on download and install process
  • Work out how to proceed on some large toolkit issues

Throwing xpcom docs out into the wild

It’s been quite some time since I last worked on my prototype XPCOM component/interface viewer and I have to face facts, it’s likely to be quite some time till I do again. I haven’t even had time to update it with the data from the latest 1.9.2 and trunk interfaces. Since I’m not likely to go anywhere else with this I’d love for someone else who thinks it is worthwhile to pick it up and run with it. I’ve just done a final commit adding a README on how to use the code (though I’m sure it is lacking in key ways so be prepared to have to experiment a bit) and the full source is available in my hg repository. The code is MPL tri-licensed so you should just be able to fork and go do your own thing. I should be able to answer any questions and would love to see it get finished and really usable somewhere.

Mossop Status Update: 2010-01-15

Done:
Started removing extension dependency support from the new EM backend.
Changed some of the API notifications to better represent add-ons that don’t require restarts.
Fixed a bug involving opening new windows after …

Done:

  • Started removing extension dependency support from the new EM backend.
  • Changed some of the API notifications to better represent add-ons that don’t require restarts.
  • Fixed a bug involving opening new windows after canceled shutdowns.

Next:

  • Work out how to handle lightweight/XPI themes in the new world order
  • Expose stubs for additional metadata to the EM API
  • Make async API work asynchronously

Mossop Status Update: 2010-01-08

Done:
Fixed a minor bug with the new extensions.checkCompatibility.X.Y pref naming
Synced up with Unfocused and Boriss on the new add-ons manager UI
Submitted a list of things we need added to AMO’s API
Posted to the com…

Done:

  • Fixed a minor bug with the new extensions.checkCompatibility.X.Y pref naming
  • Synced up with Unfocused and Boriss on the new add-ons manager UI
  • Submitted a list of things we need added to AMO’s API
  • Posted to the community about the plan to drop extension dependencies

Next:

  • Evaluate feedback from the community on dropping extension dependencies
  • Work out how to handle lightweight/XPI themes in the new world order
  • Expose stubs for additional metadata to the EM API
  • Make async API work real

Do we need extension dependencies?

Ever since Firefox 2 we have vaguely supported a form of extension dependency. That is marking an extension as requiring particular versions of another extension.

The support is currently very limited and when a user tries to use an add-on that depends on something they don’t have they are pretty much left in the cold. While we tell them it requires something we don’t tell that what it requires or give them any easy way to download and install it.

Given this poor implementation it is perhaps no surprise that very few extensions make use of the feature (something like 50 listed on AMO, many of which are outdated). This raises questions over the cost of continuing to support this feature particularly now when we are undergoing large scale changes to the add-ons manager architecture to give better support to personas and jetpacks.

Before I made any final decisions I wanted to gather some feedback on what people thought about completely dropping the support for dependencies for now. We will always have the option to add it back again (even in a more functional state) at a later time should we decide it is worthwhile. Unfortunately it’s certainly not on the cards right now to complete the implementation as it stands and even leaving it as it is is costing significant work during the refactoring project.

Extensions can always handle dependencies themselves at runtime by testing for the presence of whatever they depend on. They can even then give the user a way to get what they need which makes for a far better user experience than the platform currently offers so I’m not sure I see a convincing reason to keep the feature as it is around for now.