Using Sync on the bleeding edge? Read this!

As of last Friday, users who are using trunk builds of Firefox (desktop and mobile) or 1.5 beta versions of the Firefox Sync add-on (on at least one device) may have been seeing various errors advising users to upgrade, even though there are no upgrades available, depending on what other clients they have installed.

How do I fix this?

New versions of Sync will all work together without any known issues, but if not all of your clients are on the development channels, you may be seeing these errors, depending on your client mix.  If you are using a client that is on one of the development channels, you will need to make sure all of your clients belong to the following list.

  • Firefox Sync 1.5b6 (all add-on users, even beta/nightly users, must upgrade to this version)
  • Firefox 4 beta 7 or higher (Desktop)
  • Firefox 4 beta 1 or higher (Mobile)
  • Firefox 4 nightly builds after 20100924 (Desktop & Mobile)
  • Firefox Home v1.0.2 or higher

How will most users be affected by this change?

Firefox Sync 1.5 and Firefox 4 b7 will be released at the same time, so users who update via normal channels will get the updated Sync versions automatically, around the same time, so we expect this will be a minimal disruption for those users.  Firefox Home 1.0.2, because it is a read-only client, supports both versions, so those users who are already on 1.0.2 should not need to take any action at this time.

Why is this happening?

As all synced data is encrypted first on the client and then uploaded to the server, Sync defines a format for how data is stored.  This is necessary so that older clients can recognize when they won’t be able to read new records.  Long-time users of Sync will remember that each and every version upgrade until v1.2 required all clients to be updated.  This was easier when Sync was a prototype add-on, but not appropriate for a shipping feature, so around six months ago we did our best to stabilize the storage format, and we haven’t changed compatibility since then.  We have since realized that there was one more minor, but incompatible, change required to the format before Firefox 4, which is the change we’ve just made.


  1. Havvy says:

    Can you describe what this change is and why it wasn’t noticed in the stabilization efforts so that future attempts as standardization of storage formats do not end up having the same issue?

  2. mconnor says:

    Oops, forgot to link this:

    It’s essentially an optimization for scaling so that user data can be migrated between hosts without requiring admins to alter the data. We had not migrated users between hosts at any point until we moved to a new infrastructure, and we discovered this made it a much slower progress (altering the contents of each and every row stored in a DB is time-consuming). It’s not a use-case we had anticipated, but probably should have.

    To be clear though, it’s entirely possible that we’ll change things again if it means significant wins for performance and/or complexity. It’s entirely likely that history’s internal format will need to change to fix as an example. This is one of the key drawbacks to a client-centric system, but we feel that it is worth the tradeoff.