1254752 - Remove deprecated functions from nsIIOService

Status: RESOLVED FIXED

(Core :: DOM: Security, defect)

Comment 1

[Christoph Kerschbaumer [:ckerschb]]

Attachment: bug_1254752_remove_deprecated_functions_from_nsiioservice.patch

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.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

Jorge, I think we have to set the addon-compat flag, right? Anything else?

Comment 3

[Patrick McManus [:mcmanus]]

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?

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/65051cc8fc06c0ab2287da988191563598b89a18
Bug 1254752 - Remove deprecated functions from nsIIOService (r=mcmanus)

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

Just make sure the Target Milestone is set when the bug is fixed. Thanks!

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed this out in https://hg.mozilla.org/integration/mozilla-inbound/rev/c9218e5c95d3 for breaking some devtools tests: https://treeherder.mozilla.org/logviewer.html#?job_id=23366109&repo=mozilla-inbound

Comment 8

[Christoph Kerschbaumer [:ckerschb]]

Attachment: bug_1254752_pocket_changes.patch

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

Comment 9

[Christoph Kerschbaumer [:ckerschb]]

Attachment: bug_1254752_xpi_changes.patch

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.

Comment 10

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8728623 [details] [diff] [review]
bug_1254752_pocket_changes.patch

Looks fine to me.

Comment 11

[Christoph Kerschbaumer [:ckerschb]]

That should work now as well; setting checkin-needed!

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ce60f4cc495a
https://hg.mozilla.org/integration/mozilla-inbound/rev/0b1dbcc5db72
https://hg.mozilla.org/integration/mozilla-inbound/rev/25a61e969b4e

Comment 13

[Gary [:streetwolf52]]

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.

Comment 14

[Christoph Kerschbaumer [:ckerschb]]

(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

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ce60f4cc495a
https://hg.mozilla.org/mozilla-central/rev/0b1dbcc5db72
https://hg.mozilla.org/mozilla-central/rev/25a61e969b4e

Comment 16

[Christoph Kerschbaumer [:ckerschb]]

(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;
}

Comment 17

[[e-mail]]

TypeError: this.ioService.newChannelFromURI is not a function
resource://gre/modules/NetUtil.jsm：292

Comment 18

[Christoph Kerschbaumer [:ckerschb]]

(In reply to [e-mail] 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.

Comment 19

[noitidart]

(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

Comment 20

[Christoph Kerschbaumer [:ckerschb]]

(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

Comment 21

[noitidart]

(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?

Comment 22

[Christoph Kerschbaumer [:ckerschb]]

(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!

Comment 23

[noitidart]

Thanks updated :)

Comment 24

[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) 
        }

Comment 25

[Diego Casorran [:diegocr]]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #18)
> (In reply to [e-mail] 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

Comment 26

[Oriol Brufau [:Oriol]]

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

Comment 27

[noitidart]

(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.

Comment 28

[Oriol Brufau [:Oriol]]

(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);

Comment 29

[Christoph Kerschbaumer [:ckerschb]]

(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.

Comment 30

[Shane Caraveo (:mixedpuppy)]

(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?

Comment 31

[Christoph Kerschbaumer [:ckerschb]]

: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

Comment 32

[Christoph Kerschbaumer [:ckerschb]]

(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.

Comment 33

[Oriol Brufau [:Oriol]]

(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.

Comment 34

[noitidart]

(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.

Comment 35

[Christoph Kerschbaumer [:ckerschb]]

(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

Comment 36

[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?

Comment 37

[Christoph Kerschbaumer [:ckerschb]]

(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

Comment 38

[Christoph Kerschbaumer [:ckerschb]]

(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

Comment 39

[Oriol Brufau [:Oriol]]

(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!

Comment 40

[Jason Barnabe (np)]

(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

Comment 41

[noitidart]

(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! :)

Comment 42

[noitidart]

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?

Comment 43

[noitidart]

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

Comment 44

[Christoph Kerschbaumer [:ckerschb]]

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

Comment 45

[cat_in_136]

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)

Comment 46

[The 8472]

(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.