Closed Bug 1254752 Opened 4 years ago Closed 4 years ago

Remove deprecated functions from nsIIOService

Categories

(Core :: DOM: Security, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: ckerschb, Assigned: ckerschb)

References

(Blocks 1 open bug)

Details

(Keywords: addon-compat, dev-doc-needed)

Attachments

(3 files)

No description provided.
Assignee: nobody → mozilla
Blocks: 1006868
Status: NEW → ASSIGNED
Summary: Remove deprecated functions from nsIIoservice.idl → Remove deprecated functions from nsIIoservice
Pat, we are about to remove all appearances of SEC_NORMAL. I just realized that we added the deprecation warning for |newChannel...()| within Bug 1134096, which landed in FF40. I think it's time and safe to remove those functions completely now.

Apparently we still had one occurence within nsPluginhost which clearly has no test coverage on TRY :-) but I think the change is safe.

CC'ing also bsmedberg and jorge.
Attachment #8728157 - Flags: review?(mcmanus)
Jorge, I think we have to set the addon-compat flag, right? Anything else?
Flags: needinfo?(jorge)
Keywords: addon-compat
Comment on attachment 8728157 [details] [diff] [review]
bug_1254752_remove_deprecated_functions_from_nsiioservice.patch

Review of attachment 8728157 [details] [diff] [review]:
-----------------------------------------------------------------

can you mark 1253944 as a dup of this if apropos?
Attachment #8728157 - Flags: review?(mcmanus) → review+
Duplicate of this bug: 1253944
Just make sure the Target Milestone is set when the bug is fixed. Thanks!
Flags: needinfo?(jorge)
Hey Shane, not directly responsible for the backout of this patch but needs to be updated anyway. Apparently we didn't have a test for that in the tree. Anyway nsIAboutModule newChannel takes two arguments, see
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/about/nsIAboutModule.idl#22
Attachment #8728623 - Flags: review?(mixedpuppy)
Hey Nick, apparently the *.xpi for test browser_dbg_addon-sources.js still used ioservice.newChannel() instead of ioservice.newChannel2(). That's the only thing I updated.

>  let channel = ioservice.newChannel2(uri, 'UTF-8', null, null, systemPrincipal,
>                                      null, Ci.nsILoadInfo.SEC_NORMAL,
>                                      Ci.nsIContentPolicy.TYPE_OTHER);

I tested locally and it works just fine now.
Attachment #8728626 - Flags: review?(nfitzgerald)
Flags: needinfo?(mozilla)
Attachment #8728626 - Flags: review?(nfitzgerald) → review+
Comment on attachment 8728623 [details] [diff] [review]
bug_1254752_pocket_changes.patch

Looks fine to me.
Attachment #8728623 - Flags: review?(mixedpuppy) → review+
That should work now as well; setting checkin-needed!
Keywords: checkin-needed
Hi Chris.  Seems these patch has caused add-ons not to work.  I ran a mozregression and it points to this patch.  Add-ons that don't work are configuration mania and gui:config.  Also, the Stylish add-on has problems, clicking the edit button does nothing.


My Browser Console shows this when I click on Stylish Edit:

TypeError: ios.newChannel is not a function aboutStylishEdit.js:21:17

I also get 'ios.newChannel is not a function' messages with the other two add-ons.
(In reply to Gary [:streetwolf] from comment #13)
> Hi Chris.  Seems these patch has caused add-ons not to work.  I ran a
> mozregression and it points to this patch.  Add-ons that don't work are
> configuration mania and gui:config.  Also, the Stylish add-on has problems,
> clicking the edit button does nothing.
> 
> 
> My Browser Console shows this when I click on Stylish Edit:
> 
> TypeError: ios.newChannel is not a function aboutStylishEdit.js:21:17
> 
> I also get 'ios.newChannel is not a function' messages with the other two
> add-ons.

Hey Gary, those addons would have to update their implementation to use ios.newChannel2() [1] providing the right security arguments; see [2] for a detailed description of all the arguments.

[1] http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl#154
[2] http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl#71
Target Milestone: --- → mozilla48
(In reply to Gary [:streetwolf] from comment #13)
> My Browser Console shows this when I click on Stylish Edit:

Here is what you would have to change: Since Stylish implements nsIAboutModule, you would have to update the newChannel implementation, because nsIAboutModule newChannel() now also takes 'aLoadInfo' as an argument. Internally you have to pass that loadInfo to the newChannel function, see:

newChannel: function(aURI, aLoadInfo) {
  let ios = Cc["@mozilla.org/network/io-service;1"].getService(Ci.nsIIOService);
  let newURI = ios.newURI("chrome://stylish/content/edit.xul", null, null);
  let channel = ios.newChannelFromURIWithLoadInfo(newURI, aLoadInfo);
  channel.originalURI = aURI;
  return channel;
}
TypeError: this.ioService.newChannelFromURI is not a function
resource://gre/modules/NetUtil.jsm:292
(In reply to zhoubcfan@163.com from comment #17)
> TypeError: this.ioService.newChannelFromURI is not a function
> resource://gre/modules/NetUtil.jsm:292

Oh thanks, we need to update that as well. Do you happen to have a callstack for that as well. Is that caused by an addon? Once I update NetUtil.jsm the callsite for this NetUtil.newChannel() call needs to be updated too.
Depends on: 1256030
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #16)
> (In reply to Gary [:streetwolf] from comment #13)
> > My Browser Console shows this when I click on Stylish Edit:
> 
> Here is what you would have to change: Since Stylish implements
> nsIAboutModule, you would have to update the newChannel implementation,
> because nsIAboutModule newChannel() now also takes 'aLoadInfo' as an
> argument. Internally you have to pass that loadInfo to the newChannel
> function, see:
> 
> newChannel: function(aURI, aLoadInfo) {
>   let ios =
> Cc["@mozilla.org/network/io-service;1"].getService(Ci.nsIIOService);
>   let newURI = ios.newURI("chrome://stylish/content/edit.xul", null, null);
>   let channel = ios.newChannelFromURIWithLoadInfo(newURI, aLoadInfo);
>   channel.originalURI = aURI;
>   return channel;
> }

Thansk for noting that fix. Is it safe to update the docs with this information? Or is it subject to change. As many (many) addons use this technique for custom about pages (line 9) - https://developer.mozilla.org/en-US/docs/Custom_about:_URLs
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #20)
> (In reply to noitidart from comment #19)
> > https://developer.mozilla.org/en-US/docs/Custom_about:_URLs
> 
> Can someone update the docs please to include the new API? See also:
> http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/about/
> nsIAboutModule.idl#22

Hi Christoph, I can update it. But what exactly is the new API? Is there a new way to register about pages? Or should I simply update newChannel to use newURI/newChannelFromURIWithLoadInfo?
Depends on: 1256050
(In reply to noitidart from comment #21)
> (In reply to Christoph Kerschbaumer [:ckerschb] from comment #20)
> > (In reply to noitidart from comment #19)
> > > https://developer.mozilla.org/en-US/docs/Custom_about:_URLs
> > 
> > Can someone update the docs please to include the new API? See also:
> > http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/about/
> > nsIAboutModule.idl#22
> 
> Hi Christoph, I can update it. But what exactly is the new API? Is there a
> new way to register about pages? Or should I simply update newChannel to use
> newURI/newChannelFromURIWithLoadInfo?

The only thing that in fact changes is the signature of newChannel, which is now:
> newChannel: function(aURI, aLoadInfo) {

and internally one shouldn't use ioservice.newChannel() but rather
> ios.newChannelFromURIWithLoadInfo(newURI, aLoadInfo);

The whole function should then look like the one shown in comment 19.
Everything else remains unchanged. Does that make sense?

Thanks for your help!
Flags: needinfo?(noitidart)
Thanks updated :)
Flags: needinfo?(noitidart)
The example is updated to be this:


    newChannel: function(aURI, aSecurity_or_aLoadInfo) {
        var channel;
        if (Services.vc.compare(core.firefox.version, 48) >= 0) {
              // greater than or equal to firefox48 so aSecurity_or_aLoadInfo is aLoadInfo
              channel = Services.io.newChannelFromURIWithLoadInfo(aboutPage_page,  aSecurity_or_aLoadInfo ) 
        } else {
              // less then firefox48 aSecurity_or_aLoadInfo is aSecurity
              channel = Services.io.newChannel(aboutPage_page, null, null) 
        }
Blocks: 1256087
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #18)
> (In reply to zhoubcfan@163.com from comment #17)
> > TypeError: this.ioService.newChannelFromURI is not a function
> > resource://gre/modules/NetUtil.jsm:292
> 
> Oh thanks, we need to update that as well. Do you happen to have a callstack
> for that as well. Is that caused by an addon? Once I update NetUtil.jsm the
> callsite for this NetUtil.newChannel() call needs to be updated too.

I have some addon triggering that too, whose usage came from this example:

https://developer.mozilla.org/en-US/Add-ons/Code_snippets/File_I_O#Read_with_content_type_hint
This breaks X-notifier add-on, which uses this code:
>  var ioService = Components.classes["@mozilla.org/network/io-service;1"].getService(Ci.nsIIOService);
>  var uri = ioService.newURI(aURL, null, null);
>  var channel = ioService.newChannelFromURI(uri);

How to get that aLoadInfo parameter?

This doc should be updated too:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIIOService
(In reply to Oriol from comment #26)
> This breaks X-notifier add-on, which uses this code:
> >  var ioService = Components.classes["@mozilla.org/network/io-service;1"].getService(Ci.nsIIOService);
> >  var uri = ioService.newURI(aURL, null, null);
> >  var channel = ioService.newChannelFromURI(uri);
> 
> How to get that aLoadInfo parameter?
> 
> This doc should be updated too:
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/
> Interface/nsIIOService

It is the second argument of the newChannel method. Before the second argument used to be aSecurityInfo now it is aLoadInfo.

Thanks will update.
(In reply to noitidart from comment #27)
> It is the second argument of the newChannel method. Before the second
> argument used to be aSecurityInfo now it is aLoadInfo.

Thanks, but X-notifier doesn't have any newChannel method.
Not sure if it's the proper way, but this seems to work:
> var channel = ioService.newChannelFromURIWithLoadInfo(uri, null);
(In reply to Oriol from comment #28)
> Thanks, but X-notifier doesn't have any newChannel method.
> Not sure if it's the proper way, but this seems to work:
> > var channel = ioService.newChannelFromURIWithLoadInfo(uri, null);

Please *DON'T* use null as the second argument as the second argument is used for security checks within Firefox. If you pass null, we can't make any security guarantees. What function did you use before? I can help you find the right update.
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #29)
> (In reply to Oriol from comment #28)
> > Thanks, but X-notifier doesn't have any newChannel method.
> > Not sure if it's the proper way, but this seems to work:
> > > var channel = ioService.newChannelFromURIWithLoadInfo(uri, null);
> 
> Please *DON'T* use null as the second argument as the second argument is
> used for security checks within Firefox. If you pass null, we can't make any
> security guarantees.

That is an interesting comment.  Why allow null?
:noitidart, would you mind updating [1] as well? We need to make sure to have the right documentation for:
* newChannelFromURI2(...)
* newChannel2(...)

and also within nsIIOService2 to update the documentation to include:
* newChannelFromURIWithProxyFlags2(...)

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIIOService
Flags: needinfo?(noitidart)
(In reply to Shane Caraveo (:mixedpuppy) from comment #30)
> > > > var channel = ioService.newChannelFromURIWithLoadInfo(uri, null);
> > 
> > Please *DON'T* use null as the second argument as the second argument is
> > used for security checks within Firefox. If you pass null, we can't make any
> > security guarantees.
> 
> That is an interesting comment.  Why allow null?

We are still in the process of deprecating all the different APIs that allow to create a channel without passing a loadinfo object. In fact you are right, for this particular API call, we could deny using null. In fact I'll file a bug and get that updated.
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #29)
> Please *DON'T* use null as the second argument as the second argument is
> used for security checks within Firefox. If you pass null, we can't make any
> security guarantees. What function did you use before? I can help you find
> the right update.

OK, thanks for the info. X-notifier defines a constructor with a method like this:
> Handler.prototype.getHtml = function(aURL) {
>   var ioService = Components.classes["@mozilla.org/network/io-service;1"].getService(Ci.nsIIOService);
>   var uri = ioService.newURI(aURL, null, null);
>   var channel = ioService.newChannelFromURI(uri);
>   var httpChannel = channel.QueryInterface(Ci.nsIHttpChannel);
>   this.channel=channel;
>   channel.notificationCallbacks = this;
>   channel.asyncOpen(this,httpChannel);
> }
(https://addons.mozilla.org/firefox/files/browse/385826/file/components/Handler.js#L424)

And then it calls that like
> var hdl = new Handler();
> hdl.getHtml("http://xnotifier.tobwithu.com/alive.php");
(https://addons.mozilla.org/firefox/files/browse/385826/file/components/Main.js#L356)

I removed code that seemed irrelevant.
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #31)
> :noitidart, would you mind updating [1] as well? We need to make sure to
> have the right documentation for:
> * newChannelFromURI2(...)
> * newChannel2(...)
> 
> and also within nsIIOService2 to update the documentation to include:
> * newChannelFromURIWithProxyFlags2(...)
> 
> [1]
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/
> Interface/nsIIOService

Done :)

Does need some more technical meat (in the param definition section). Hyperlinks/Anchors, Signatures, and Min/Max/Deprecated Fx versions updated though.
Flags: needinfo?(noitidart)
(In reply to noitidart from comment #34)
> Done :)
> 
> Does need some more technical meat (in the param definition section).
> Hyperlinks/Anchors, Signatures, and Min/Max/Deprecated Fx versions updated
> though.

:noitidart, thanks for updating. Do you mind fixing some nits real quick:
* newChannel2() [1]
Could you please copy argument descriptions from here [2]. You already did that for newChannelFromURI2() - looks good.

* newChannelFromURIWithProxyFlags2 [4]
is not part of nsIIOService but of nsIIOService2 (please note the *2* in the end) - we need to update that as well.

Thanks for taking on that work!

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIIOService#newChannel2%28%29
[2] http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.idl#73
[3] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIIOService#newChannelFromURI2%28%29
[4] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIIOService#newChannelFromURIWithProxyFlags2%28%29
[5] http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.idl#97
Flags: needinfo?(noitidart)
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #35)
> (In reply to noitidart from comment #34)
> > Done :)
> > 
> > Does need some more technical meat (in the param definition section).
> > Hyperlinks/Anchors, Signatures, and Min/Max/Deprecated Fx versions updated
> > though.
> 
> :noitidart, thanks for updating. Do you mind fixing some nits real quick:
> * newChannel2() [1]
> Could you please copy argument descriptions from here [2]. You already did
> that for newChannelFromURI2() - looks good.
> 
> * newChannelFromURIWithProxyFlags2 [4]
> is not part of nsIIOService but of nsIIOService2 (please note the *2* in the
> end) - we need to update that as well.
> 
> Thanks for taking on that work!
> 
> [1]
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/
> Interface/nsIIOService#newChannel2%28%29
> [2]
> http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService.
> idl#73
> [3]
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/
> Interface/nsIIOService#newChannelFromURI2%28%29
> [4]
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/
> Interface/nsIIOService#newChannelFromURIWithProxyFlags2%28%29
> [5]
> http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIIOService2.
> idl#97

Cool updated it.

About nsIIOService2, is it just `newChannelFromURIWithProxyFlags2` or do all things ending with 2 need to be moved to the nsIIOService2 doc page?
Flags: needinfo?(noitidart)
(In reply to Oriol from comment #33)
> > Handler.prototype.getHtml = function(aURL) {
> >   var ioService = Components.classes["@mozilla.org/network/io-service;1"].getService(Ci.nsIIOService);
> >   var uri = ioService.newURI(aURL, null, null);
> >   var channel = ioService.newChannelFromURI(uri);
> >   var httpChannel = channel.QueryInterface(Ci.nsIHttpChannel);
> >   this.channel=channel;
> >   channel.notificationCallbacks = this;
> >   channel.asyncOpen(this,httpChannel);
> > }

Some of that code seems slightly off, e.g. the httpchannel and the channel is the same object. Now, depending on how onStartRequest and onStopRequest is implemented you potentially have to slightly update that code because asyncOpen2() does not take a second argument anymore [1]. Anyway, here is what I think the code should look like.

Handler.prototype.getHtml = function(aURL) {
  var channel = NetUtil.newChannel({uri: aURL, loadUsingSystemPrincipal: true});
  channel.notificationCallbacks = this;
  channel.asyncOpen2(this);
}

[1] http://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsIChannel.idl#199
(In reply to noitidart from comment #36)
> About nsIIOService2, is it just `newChannelFromURIWithProxyFlags2` or do all
> things ending with 2 need to be moved to the nsIIOService2 doc page?

Yes, it's only newChannelFromURIWithProxyFlags2 that needs to be moved to nsIIOService2 (as far I as can tell, that page does not exist yet [1]). Other than that, nsIIOService [2] looks good now - thanks!


[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIIOService
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #37)
> depending on how onStartRequest and onStopRequest
> is implemented you potentially have to slightly update that code because
> asyncOpen2() does not take a second argument anymore

That's the problem. onStartRequest doesn't use the 2nd parameter, but onStopRequest does:

  onStopRequest: function (aRequest, aContext, aStatus) {
    if(aStatus == Components.results.NS_BINDING_ABORTED) return;
    // ...
    this.doNext(this.hData, aContext.QueryInterface(Ci.nsIHttpChannel));
  }

But is asyncOpen obsolete? This seems to work:

  Handler.prototype.getHtml = function(aURL) {
    Components.utils.import("resource://gre/modules/NetUtil.jsm");
    var channel = NetUtil.newChannel({uri: aURL, loadUsingSystemPrincipal: true});
    var httpChannel = channel.QueryInterface(Ci.nsIHttpChannel);
    channel.notificationCallbacks = this;
    channel.asyncOpen(this, httpChannel);
  }

Thanks!
(In reply to noitidart from comment #24)
> The example is updated to be this:
> 
> 
>     newChannel: function(aURI, aSecurity_or_aLoadInfo) {
>         var channel;
>         if (Services.vc.compare(core.firefox.version, 48) >= 0) {
>               // greater than or equal to firefox48 so
> aSecurity_or_aLoadInfo is aLoadInfo
>               channel =
> Services.io.newChannelFromURIWithLoadInfo(aboutPage_page, 
> aSecurity_or_aLoadInfo ) 
>         } else {
>               // less then firefox48 aSecurity_or_aLoadInfo is aSecurity
>               channel = Services.io.newChannel(aboutPage_page, null, null) 
>         }

ReferenceError: Services is not defined
(In reply to Jason Barnabe (np) from comment #40)
> (In reply to noitidart from comment #24)
> > The example is updated to be this:
> > 
> > 
> >     newChannel: function(aURI, aSecurity_or_aLoadInfo) {
> >         var channel;
> >         if (Services.vc.compare(core.firefox.version, 48) >= 0) {
> >               // greater than or equal to firefox48 so
> > aSecurity_or_aLoadInfo is aLoadInfo
> >               channel =
> > Services.io.newChannelFromURIWithLoadInfo(aboutPage_page, 
> > aSecurity_or_aLoadInfo ) 
> >         } else {
> >               // less then firefox48 aSecurity_or_aLoadInfo is aSecurity
> >               channel = Services.io.newChannel(aboutPage_page, null, null) 
> >         }
> 
> ReferenceError: Services is not defined

Thanks, in the example its more complete there is a `Components.utils.import("resource://gre/modules/Services.jsm");` at the top there. If I missed it, someone added. Long live wiki style! :)
Summary: Remove deprecated functions from nsIIoservice → Remove deprecated functions from nsIIOService
Hi all,
In the updated custom about uri example, I actually tested it now, and it's throwing this error - 

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIChannel.open2]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/RemoteAddonsParent.jsm :: AboutProtocolParent.openChannel :: line 276"  data: no]

Anyone know how to fix this?
I think I was mistaken. Since when was the second arg of newChannel made to be aLoadInfo?

Is it safe to use newChannelFromURIWithLoadInfo with the second argument of newChannel since Fx37? I tested it in Fx45 and it works. MXR release, which is Fx45 was using newChannelFromURIWithLoadInfo  with the second arg of newChannel, which I thought was aSecurity? http://mxr.mozilla.org/mozilla-release/source/browser/base/content/test/general/browser_devices_get_user_media_about_urls.js#209
Blocks: 1257201
Depends on: 1257339
Moving forward with this we decided to bring back the API, updating some of the arguments internally, see:
> Bug 1257339 - Bring back deprecated newChannel() API on nsIIOService
No longer depends on: 1257339
Blocks: 1257339
No longer depends on: 1257111
Hi, all. I use this method to define a custom about: URI on my addon.

(In reply to noitidart from comment #43)
> Is it safe to use newChannelFromURIWithLoadInfo with the second argument of
> newChannel since Fx37? I tested it in Fx45 and it works.

I think so. I tested it in Firefox 36 on Linux x64 and it works well.
I believe that MDN page SHOULD be fixed because of this misdescription.

> MXR release, which
> is Fx45 was using newChannelFromURIWithLoadInfo  with the second arg of
> newChannel, which I thought was aSecurity?

I could not find out "aSecurity":

 * Bug 1111025 introduced new method: nsIIOService#newChannelFromURIWithLoadInfo(in nsIURI aURI, in nsILoadInfo aLoadInfo) (version: 37)
 * Bug 1067468 added a LoadInfo to the argument of nsAboutBloat::NewChannel(nsIURI *aURI) (version: 36)
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)
> Pat, we are about to remove all appearances of SEC_NORMAL. I just realized
> that we added the deprecation warning for |newChannel...()| within Bug
> 1134096, which landed in FF40. I think it's time and safe to remove those
> functions completely now.

Btw, the replacement, newChannel2 and newChannelFromURIWithLoadInfo were not documented until recently. I only ran into them while reading the .idl and added the latter, noitidart adding the former.

Similarly nsIProtocolHandler MDN page documents  newChannel, but the idl also has a newChannel2.

If the documentation is not up to date then addon developers operate on outdated information, making the compatibility situation worse than it needs to be.

Copying from the IDL contents manually and editing the wiki to conform to its documentation style is quite tedious. Is there no way to convert the IDLs into a wiki code snippet?
If there is no such thing then of course it's no surprise that the documentation is outdated. If it exists then it would be nice it would be used when interfaces change / methods become deprecated.
You need to log in before you can comment on or make changes to this bug.