Bunch of API changes on trunk break many add-ons

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bunch of API changes on trunk break many add-ons

Jonathan Kamens-4
There are a bunch of API changes recently checked into
comm-central which break a bunch of add-ons. The ones I've
noticed so far are Google Contacts, Show InOut, Show Folder
Size, and Send Later.

Changes include converting a whole bunch of nsISupportsArray
to nsIArray and renaming GetIdentitiesForServer to
getIdentitiesForServer in nsIAccountManager.

One wonders what the point is of supporting the ability to
version interfaces when the folks who maintain Thunderbird
don't actually use it to provide backward compatibility for
old interface versions. That is, code which does this:

var accountManager = Components
  .classes["@mozilla.org/messenger/account-manager;1"]
  .getService(Components.interfaces.nsIMsgAccountManager);

Should continue to work essentially forever, or at the very
least for a very long time. If the interface changes, the new
interface should either have a different name or should be in
the class array with ";2" rather than ";1".

Having said that, could these incompatible changes please be
documented somewhere, quickly, in a user-friendly way, so that
those of us who maintain add-ons can update them to be
compatible before TB20 comes out? It would also be really
helpful, also, to put together some sort of document with
suggestions for updating code in a backward-compatible way.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Bunch of API changes on trunk break many add-ons

Jonathan Protzenko
Thanks Jonathan for the good recap of all major changes. One other that
I've noticed is:
- a whole bunch of functions in the phishing manager have been renamed
(window.gPhishingDetector).

I think an easy thing to do would be for the authors of these patches
to drop a note in this very newsgroup to give us addon authors a
heads-up. I'm running Daily just for the sake of catching breakages
early (and I certainly don't catch them all, unfortunately...).

For the record (in case anyone is stratching their heads), there are
other subtle changes in Gecko that broke Conversations:
- the behavior of Iterator for HTMLNodeCollection in Gecko changed to
yield more items,
- it's apparently no longer possible to define a function of your own
named "top"
- exposing data from chrome to content got stricter (need to
specifically expose the desired properties).

Hope that helps,

jonathan

On Tue 18 Dec 2012 10:58:08 PM CET, Jonathan Kamens wrote:

> There are a bunch of API changes recently checked into
> comm-central which break a bunch of add-ons. The ones I've
> noticed so far are Google Contacts, Show InOut, Show Folder
> Size, and Send Later.
>
> Changes include converting a whole bunch of nsISupportsArray
> to nsIArray and renaming GetIdentitiesForServer to
> getIdentitiesForServer in nsIAccountManager.
>
> One wonders what the point is of supporting the ability to
> version interfaces when the folks who maintain Thunderbird
> don't actually use it to provide backward compatibility for
> old interface versions. That is, code which does this:
>
> var accountManager = Components
>    .classes["@mozilla.org/messenger/account-manager;1"]
>    .getService(Components.interfaces.nsIMsgAccountManager);
>
> Should continue to work essentially forever, or at the very
> least for a very long time. If the interface changes, the new
> interface should either have a different name or should be in
> the class array with ";2" rather than ";1".
>
> Having said that, could these incompatible changes please be
> documented somewhere, quickly, in a user-friendly way, so that
> those of us who maintain add-ons can update them to be
> compatible before TB20 comes out? It would also be really
> helpful, also, to put together some sort of document with
> suggestions for updating code in a backward-compatible way.
> _______________________________________________
> dev-apps-thunderbird mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Bunch of API changes on trunk break many add-ons

Joshua Cranmer-2
In reply to this post by Jonathan Kamens-4
On 12/18/2012 3:58 PM, Jonathan Kamens wrote:

> There are a bunch of API changes recently checked into
> comm-central which break a bunch of add-ons. The ones I've
> noticed so far are Google Contacts, Show InOut, Show Folder
> Size, and Send Later.
>
> Changes include converting a whole bunch of nsISupportsArray
> to nsIArray and renaming GetIdentitiesForServer to
> getIdentitiesForServer in nsIAccountManager.
>
> One wonders what the point is of supporting the ability to
> version interfaces when the folks who maintain Thunderbird
> don't actually use it to provide backward compatibility for
> old interface versions. That is, code which does this:

All interfaces in Gecko and mailnews have been considered unfrozen and
liable to change since version 4. The interfaces in fact are versioned;
on every ABI-breaking change, we modify the UUID of the interface (which
causes C++ code to work more correctly), and this change can be observed
via some advanced features of XPCOM. However, it's often just easier to
test for the presence of a method in JS.
>
> var accountManager = Components
>    .classes["@mozilla.org/messenger/account-manager;1"]
>    .getService(Components.interfaces.nsIMsgAccountManager);
>
> Should continue to work essentially forever, or at the very
> least for a very long time. If the interface changes, the new
> interface should either have a different name or should be in
> the class array with ";2" rather than ";1".

We do not have the staff to maintain this kind of backwards
compatibility. In particular, note that the nsISupportsArray-to-nsIArray
change also necessitates changing the internal storage of the account
manager, so there is absolutely no way a backwards-compatible API could
have been made in the first place without involving seriously ugly
hacks. Changing interface names would gratuitously break add-ons that
use the interface but not those methods, and changing the contract ID of
such a major service is a sure-fire way to break something.
>
> Having said that, could these incompatible changes please be
> documented somewhere, quickly, in a user-friendly way, so that
> those of us who maintain add-ons can update them to be
> compatible before TB20 comes out? It would also be really
> helpful, also, to put together some sort of document with
> suggestions for updating code in a backward-compatible way.
We do update the AMO add-on checker with all interface changes, but that
only happens on the final release version AIUI. There is a series of
pages on devmo entitled "Firefox N for developers" which lists these
kind of changes, and Thunderbird had a corresponding set for a while,
but it appears that we stopped maintaining these pages? I would expect
that most changes to comm-central would lag in any public forum, but
ideally, we ought to have complete-ish lists by the time it moves into
aurora.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Bunch of API changes on trunk break many add-ons

Mark Banner-4
On 18/12/2012 23:07, Joshua Cranmer wrote:

> On 12/18/2012 3:58 PM, Jonathan Kamens wrote:
>> There are a bunch of API changes recently checked into
>> comm-central which break a bunch of add-ons. The ones I've
>> noticed so far are Google Contacts, Show InOut, Show Folder
>> Size, and Send Later.
>>
>> Changes include converting a whole bunch of nsISupportsArray
>> to nsIArray and renaming GetIdentitiesForServer to
>> getIdentitiesForServer in nsIAccountManager.
>>
>> One wonders what the point is of supporting the ability to
>> version interfaces when the folks who maintain Thunderbird
>> don't actually use it to provide backward compatibility for
>> old interface versions. That is, code which does this:
>
> All interfaces in Gecko and mailnews have been considered unfrozen and
> liable to change since version 4. The interfaces in fact are versioned;
> on every ABI-breaking change, we modify the UUID of the interface (which
> causes C++ code to work more correctly), and this change can be observed
> via some advanced features of XPCOM. However, it's often just easier to
> test for the presence of a method in JS.

Joshua is right here, the interfaces have always been liable to change
between versions.

In this case nsISupportsArray is an obsolete structure that has various
problems, and hence is being replaced by nsIArray. This is something
I've been doing bits on over the last couple of years for Thunderbird,
but recent gecko changes caused the most recent changes - they seem to
be actively working on removing nsISupportsArray completely, and we need
to follow along.

>> Having said that, could these incompatible changes please be
>> documented somewhere, quickly, in a user-friendly way, so that
>> those of us who maintain add-ons can update them to be
>> compatible before TB20 comes out?

TB 20 will only be released to the beta channel, it will be TB 24 before
these changes make it live
(https://wiki.mozilla.org/Thunderbird/New_Release_and_Governance_Model#Releases)

 >> It would also be really
>> helpful, also, to put together some sort of document with
>> suggestions for updating code in a backward-compatible way.
...
 > There is a series of
> pages on devmo entitled "Firefox N for developers" which lists these
> kind of changes, and Thunderbird had a corresponding set for a while,
> but it appears that we stopped maintaining these pages?

Getting developer input was difficult, and generally we found the add-on
compatibility notifications were more instructive than the page.


As to the apis that have actually changed, there's information on how to
get those here:

https://wiki.mozilla.org/Thunderbird/Release_Driving/Rapid_Release_Activities/Compatibility_Bump

(for comm-central, but could easily be applied to mozilla-central).

The current diff shows the interfaces that the attributes for the
following changed from nsISupportsArray -> nsIArray:

- nsIMsgAccount.identities
- nsIMsgAccountManager.accounts
- nsIMsgAccountManager.allIdentities
- nsIMsgAccountManager.allServers

The following functions have also changed:

- nsIMsgAccountManager.GetIdentitiesForServer replaced by
nsIMsgAccountManager.getIdentitiesForServer with return type changed
- nsIMsgAccountManager.GetServersForIdentity replaced by
nsIMsgAccountManager.getServersForIdentity with return type changed

The following function was removed due to not being used:

- nsIMsgFolder.getExpansionArray


To deal with backwards compatibility, you have two options (hints of
which can be found in the diffs of the bugs that landed).

1) Use fixIterator in iteratorUtils.js to turn the array into a for each
loop (this supports nsIArray and nsISupportsArray)

e.g.
http://hg.mozilla.org/comm-central/annotate/cf6e1013c175/mail/base/modules/MailUtils.js#l31

fixIterator has been available since around TB 3 (only in TB, not in FF
at all).

2) Do function/type detection. You can easily work this out comparing
nsISupportsArray.idl and nsIArray.idl. However, mostly there's two
functions that are mostly used.

- .Count() is replaced by .length
- .QueryElementAt is replaced by .queryElementAt


If anyone wants to take these and document them, that'd be a great help.

Note that I expect there will be more nsISupportsArray -> nsIArray
changes over the next couple of months as the obsolete structure gets
removed more.

Mark.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Thunderbird release model (was: Re: Bunch of API changes on trunk break many add-ons)

Jonathan Kamens-4
Mark Banner <[hidden email]> writes:
>TB 20 will only be released to the beta channel, it will be TB 24 before
>these changes make it live
>(https://wiki.mozilla.org/Thunderbird/New_Release_and_Governance_Model#Releases)

I think this must be a change in policy, because as I
understand it, up until now the public releases incremented
by one every time.

I read the text at the link you sent, and frankly it's
gobbledygook to me and I don't know how a person not familiar
with all the gruesome details of the release model would be
able to understand what it means. However, as best as I can
tell, although that text suggests that the frequency of public
releases is going to go down, it doesn't indicate how an
add-on developer like me, or anyone else, can tell whether any
particular numbered released is going to go out to the public.

There may have been a lot of complaining about the frequency
of numbered releases when they were sequential, but at least
that was comprehensible. This new model, if indeed I'm
understanding correctly that it's a new model, seems rather
confusing.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: Bunch of API changes on trunk break many add-ons

gNeandr-7
In reply to this post by Mark Banner-4
On 19.12.2012 10:25, Mark Banner wrote:

> On 18/12/2012 23:07, Joshua Cranmer wrote:
>> On 12/18/2012 3:58 PM, Jonathan Kamens wrote:
>>> There are a bunch of API changes recently checked into
>>> comm-central which break a bunch of add-ons. The ones I've
>>> noticed so far are Google Contacts, Show InOut, Show Folder
>>> Size, and Send Later.
>>>
>>> Changes include converting a whole bunch of nsISupportsArray
>>> to nsIArray and renaming GetIdentitiesForServer to
>>> getIdentitiesForServer in nsIAccountManager.
>>>
>>> One wonders what the point is of supporting the ability to
>>> version interfaces when the folks who maintain Thunderbird
>>> don't actually use it to provide backward compatibility for
>>> old interface versions. That is, code which does this:
>>
>> All interfaces in Gecko and mailnews have been considered unfrozen and
>> liable to change since version 4. The interfaces in fact are versioned;
>> on every ABI-breaking change, we modify the UUID of the interface (which
>> causes C++ code to work more correctly), and this change can be observed
>> via some advanced features of XPCOM. However, it's often just easier to
>> test for the presence of a method in JS.
>
> Joshua is right here, the interfaces have always been liable to change
> between versions.
>
> In this case nsISupportsArray is an obsolete structure that has various
> problems, and hence is being replaced by nsIArray. This is something
> I've been doing bits on over the last couple of years for Thunderbird,
> but recent gecko changes caused the most recent changes - they seem to
> be actively working on removing nsISupportsArray completely, and we need
> to follow along.
>
>>> Having said that, could these incompatible changes please be
>>> documented somewhere, quickly, in a user-friendly way, so that
>>> those of us who maintain add-ons can update them to be
>>> compatible before TB20 comes out?
>
> TB 20 will only be released to the beta channel, it will be TB 24 before
> these changes make it live
> (https://wiki.mozilla.org/Thunderbird/New_Release_and_Governance_Model#Releases)
>
>
>  >> It would also be really
>>> helpful, also, to put together some sort of document with
>>> suggestions for updating code in a backward-compatible way.
> ...
>  > There is a series of
>> pages on devmo entitled "Firefox N for developers" which lists these
>> kind of changes, and Thunderbird had a corresponding set for a while,
>> but it appears that we stopped maintaining these pages?
>
> Getting developer input was difficult, and generally we found the add-on
> compatibility notifications were more instructive than the page.
>
>
> As to the apis that have actually changed, there's information on how to
> get those here:
>
> https://wiki.mozilla.org/Thunderbird/Release_Driving/Rapid_Release_Activities/Compatibility_Bump
>
>
> (for comm-central, but could easily be applied to mozilla-central).
>
> The current diff shows the interfaces that the attributes for the
> following changed from nsISupportsArray -> nsIArray:
>
> - nsIMsgAccount.identities
> - nsIMsgAccountManager.accounts
> - nsIMsgAccountManager.allIdentities
> - nsIMsgAccountManager.allServers
>
> The following functions have also changed:
>
> - nsIMsgAccountManager.GetIdentitiesForServer replaced by
> nsIMsgAccountManager.getIdentitiesForServer with return type changed
> - nsIMsgAccountManager.GetServersForIdentity replaced by
> nsIMsgAccountManager.getServersForIdentity with return type changed
>
> The following function was removed due to not being used:
>
> - nsIMsgFolder.getExpansionArray
>
>
> To deal with backwards compatibility, you have two options (hints of
> which can be found in the diffs of the bugs that landed).
>
> 1) Use fixIterator in iteratorUtils.js to turn the array into a for each
> loop (this supports nsIArray and nsISupportsArray)
>
> e.g.
> http://hg.mozilla.org/comm-central/annotate/cf6e1013c175/mail/base/modules/MailUtils.js#l31
>
>
> fixIterator has been available since around TB 3 (only in TB, not in FF
> at all).
>
> 2) Do function/type detection. You can easily work this out comparing
> nsISupportsArray.idl and nsIArray.idl. However, mostly there's two
> functions that are mostly used.
>
> - .Count() is replaced by .length
> - .QueryElementAt is replaced by .queryElementAt
>
>
> If anyone wants to take these and document them, that'd be a great help.
>
> Note that I expect there will be more nsISupportsArray -> nsIArray
> changes over the next couple of months as the obsolete structure gets
> removed more.
>
> Mark.
Does this mean to me -- as an author for an extension running on Firefox
and Thunderbird -- I have to check out both of the whole FX/TB code to
follow which interfaces **are going to change** ?

I feel that's the end of supporting Mozilla with extensions ..

Günter
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird