IID Changes to Some Gecko 1.9.1 Interfaces

Christopher Blizzard

4

This post is here to warn a subset of add-on authors that we’re making some late changes to the IID for some interfaces on the Gecko 1.9.1 branch.  A very small subset of people are likely affected based on our scan of a bunch of add-ons.  Note that this doesn’t affect the methods on the interfaces themselves, just the IIDs for interfaces.  So it should not require a functional change.

What we’re changing:

Based on a report on the dev-platform mailing list there are some interfaces that were changed between Gecko 1.8.0 and Gecko 1.9.0 without changing the IID for that interface.  Gecko 1.9.1, which inherited the code from Gecko 1.9.0, currently contains this error as well.  [Note that most of the discussion of the reported issue appears to be missing from Google Groups.  We are not sure why this is, but we assure you there was a long discussion of the issues.]

There are apparently some extensions for Thunderbird which need to be able to detect which version of an interface is being used based on the IID.  (Thunderbird 2 and Firefox 2 were both based on Gecko 1.8.0 and Thunderbird 3 and Firefox 3.1 will be based on Gecko 1.9.1.)  In order to make detecting that difference possible we need to make the change in the 1.9.1 branch before we release Firefox 3.1, as that will also serve as the baseline for Thunderbird 3.

These are the affected interfaces listed in the post and have been changed ahead of the release of Firefox 3.1 Beta 3:

475897 imgIContainer
475898 jsdIDebuggerService
475900 nsIAbDirectoryQueryArguments
475901 nsIAccessibleValue
475912 nsITokenDialogs
475913 nsIXULWindow
475915 nsPIWindowWatcher

These interfaces will be changed by the mailnews team before the release of Thunderbird 3:

475909 nsIMailtoUrl
475903 nsIFolderListener
475904 nsIImapMailFolderSink
475906 nsIImportMail nsIImportMailboxDescriptor
475907 nsINNTPNewsgroupList

Am I affected?

Very few people are likely affected by this change.  You might be affected if:

  1. Your extension includes binary components written in C++ and uses the affected interfaces.
  2. Your extension is loading an affected component using the IID instead of by name.

JavaScript-only extensions that refer to components by name instead of by IID will not be affected by this change.  This is almost all extensions.

What do I have to do if I’m affected?

If you’ve got an affected C++ component all you will have to do is rebuild your component with the new header files and re-release it.  We’re not changing interfaces, just the IID associated with them.

If you’ve got a component in JavaScript and you’re using interfaces by IID instead of name you will have to change the IID in your extension and re-release.

4 responses

  1. Brian King wrote on ::

    Bug links are busted.

  2. blizzard wrote on :

    Argh, thanks. Fixed now.

  3. Boris wrote on :

    nsIAbDirectoryQueryArguments hasn’t been changed yet, since it’s a mailnews interface.

  4. grubshka wrote on ::

    nsIXPConnect changed of UUID between 3.1b2 and 3.1b3 too.

    It’s a problem for extensions that make use of this : do we need to make 2 different versions of the extension ?