Mossop Status Update: 2010-03-12

Posted: March 12th, 2010

Done:

  • Wired up installs and blocked installs from webpages
  • Converted the xpinstall test suite to work with the new APIs
  • Started preparing the project branch for performance testing

Next:

  • Finish support for extensions that don't need restarts
  • Personas and plugins support
  • Background auto-updates
  • Convert the old EM test suite to the new APIs
  • Make sure the API docs are in sync with the code
  • Make a list of things not yet implemented for QA
  • Put together a plan for a trunk landing

Tags: , ,

No Comments »

Categories: mozilla

Mossop Status Update: 2010-03-05

Posted: March 5th, 2010

Done:

  • Firefox team shenanigans
  • True async reads for the add-ons manager
  • Compatibility overrides and compatibility updates
  • Figured out how to integrate webpage triggered installs

Next:

  • Webpage installs
  • Personas and plugins support

Coordination:

Need to see if releng can get the project branch set up this week

Tags: , ,

No Comments »

Categories: mozilla

Mossop Status Update: 2010-02-26

Posted: February 26th, 2010

Done:

  • Catching up on a backlog of reviews
  • Planned out how to integrate the existing InstallTrigger code with the new EM backend
  • Handle migrating extension states from older/newer versions of Firefox

Next:

  • Make installs from webpages work again
  • Work out a list of things to do before a trunk landing is possible
  • Party with the rest of the team

Tags: , ,

No Comments »

Categories: mozilla

Mossop Status Update: 2010-02-19

Posted: February 19th, 2010

Done:

  • Worked through install and upgrade scenarios with Boriss
  • Implemented downloading and updating add-ons through the API
  • Implemented updating add-on compatibility on app upgrade

Next:

  • Make installs from webpages work again
  • Handle migrating data from newer/older versions

Tags: , ,

No Comments »

Categories: mozilla

Mossop Status Update: 2010-02-05

Posted: February 5th, 2010

Done:

Lost most of the week to sickness but trawled through some reviews that were blocking people's work.

Next:

  • Downloads and updates in the add-ons API

Tags: , ,

No Comments »

Categories: mozilla

Mossop Status Update: 2010-01-29

Posted: January 29th, 2010

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.

Tags: , ,

No Comments »

Categories: mozilla

Mossop Status Update: 2010-01-22

Posted: January 22nd, 2010

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

Tags: , ,

No Comments »

Categories: mozilla

Mossop Status Update: 2010-01-15

Posted: January 15th, 2010

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

Tags: , ,

No Comments »

Categories: mozilla

Mossop Status Update: 2010-01-08

Posted: January 8th, 2010

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

Tags: , ,

No Comments »

Categories: mozilla

Changing the checkCompatibility preference

Posted: November 6th, 2009

Back in the mists of time I wrote some code to make nightly testers’ lives easier by giving them a simple preference to flip if they wanted to be able to install and use incompatible extensions. It’s been more than three years since then and the use of this preference has grown beyond its original use. It is now something recommended to regular users everywhere from forums to comments in news articles as a way to use their extensions in the new major Firefox releases.

Don’t get me wrong, letting users upgrade sooner than they otherwise might is a good thing, but the preference is a dangerous beast. It is pretty simple for a user to set the preference and then forget about it leaving them able to install incompatible extensions that break their Firefox without realising it. This costs Mozilla time as well since we get quite a number of bug and crash reports to look at that turn out to be caused by extensions that are dutifully marked incompatible with the user’s Firefox.

We’ve been mulling over ways to change this for a while but now we’ve actually gone and done something about it. We still want nightly testers and early adopters to be able to use incompatible extensions if they need to but we also want to make the preference not be a one shot deal that lasts till the end of time. The plan we’ve come up with is to change the preference’s name with the Firefox version, so for Firefox 3.6 (and all security releases) the preference will be extensions.checkCompatibility.3.6. When switching to a future 3.7 testers and users will have to set a new pref extensions.checkCompatibility.3.7 to say they still accept the risks of running with incompatible stuff.

Nightly users will have to make the changes slightly more often since the preference will also track whether the version is one of the development alphas or betas, so for the 3.6 betas the preference would be extensions.checkCompatibility.3.6b, for the current trunk extensions.checkCompatibility.3.7a. These are just normal preferences of course, if you frequently switch between different Firefox versions you can just set both necessary preferences. The change should land on the trunk in the next day or so and then the 3.6 builds a day or so after that.

There is just one oddity, if you’re testing nightlies and you update to a build with the change then you likely won’t notice any of your extensions disabling themselves, that won’t happen till either you toggle the pref or you switch to a build with a different Firefox version number in it.

Update: For more in-depth information this change was made in bug 521905.

Tags: , , , ,

34 Comments »

Categories: mozilla