1071497 - error: no matching function for call to ‘NS_NewStreamLoader(nsGetterAddRefs<nsIStreamLoader>, nsCOMPtr<nsIURI>&, nsAbContentHandler* const, nsIInterfaceRequestor*&)’

Status: RESOLVED FIXED

(MailNews Core :: Address Book, defect)

Description

[Edmund Wong (:ewong)]

While I'm looking at SeaMonkey comm-central build, I believe this should
be tagged MailNews-Build Config. 

Currently there's a bustage in comm-central:

/usr/bin/ccache /tools/gcc-4.7.3-0moz1/bin/g++ -o nsMsgIncomingServer.o -c -I../../../dist/stl_wrappers -I../../../dist/system_wrappers -include /builds/slave/c-cen-t-lnx/build/mozilla/config/gcc_hidden.h -D_IMPL_NS_MSG_BASE -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DMOZ_GLUE_IN_PROGRAM -DOSTYPE=\"Linux2.6.32-220.7.1.el6\" -DOSARCH=Linux -DNO_NSPR_10_SUPPORT -I/builds/slave/c-cen-t-lnx/build/mailnews/base/util -I.  -I../../../dist/include  -I/builds/slave/c-cen-t-lnx/build/objdir/dist/include/nspr -I/builds/slave/c-cen-t-lnx/build/objdir/dist/include/nss       -fPIC   -DMOZILLA_CLIENT -include ../../../mozilla-config.h -MD -MP -MF .deps/nsMsgIncomingServer.o.pp  -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Werror=int-to-pointer-cast -Werror=type-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wcast-align -gdwarf-2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -gdwarf-2 -freorder-blocks -Os  -fno-omit-frame-pointer      /builds/slave/c-cen-t-lnx/build/mailnews/base/util/nsMsgIncomingServer.cpp
nsMsgKeyArray.cpp
/usr/bin/ccache /tools/gcc-4.7.3-0moz1/bin/g++ -o nsAbContentHandler.o -c -I../../../dist/stl_wrappers -I../../../dist/system_wrappers -include /builds/slave/c-cen-t-lnx/build/mozilla/config/gcc_hidden.h -DMOZ_LDAP_XPCOM -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DMOZ_GLUE_IN_PROGRAM -DOSTYPE=\"Linux2.6.32-220.7.1.el6\" -DOSARCH=Linux -DNO_NSPR_10_SUPPORT -I/builds/slave/c-cen-t-lnx/build/mailnews/addrbook/src -I.  -I../../../dist/include  -I/builds/slave/c-cen-t-lnx/build/objdir/dist/include/nspr -I/builds/slave/c-cen-t-lnx/build/objdir/dist/include/nss       -fPIC   -DMOZILLA_CLIENT -include ../../../mozilla-config.h -MD -MP -MF .deps/nsAbContentHandler.o.pp  -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Werror=int-to-pointer-cast -Werror=type-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wcast-align -gdwarf-2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -gdwarf-2 -freorder-blocks -Os  -fno-omit-frame-pointer      /builds/slave/c-cen-t-lnx/build/mailnews/addrbook/src/nsAbContentHandler.cpp
nsAbDirectoryQuery.cpp
../../../../mailnews/addrbook/src/nsAbContentHandler.cpp: In member function ‘virtual nsresult nsAbContentHandler::HandleContent(const char*, nsIInterfaceRequestor*, nsIRequest*)’:
../../../../mailnews/addrbook/src/nsAbContentHandler.cpp:116:84: error: no matching function for call to ‘NS_NewStreamLoader(nsGetterAddRefs<nsIStreamLoader>, nsCOMPtr<nsIURI>&, nsAbContentHandler* const, nsIInterfaceRequestor*&)’
../../../../mailnews/addrbook/src/nsAbContentHandler.cpp:116:84: note: candidates are:
In file included from ../../../../mailnews/addrbook/src/nsAbContentHandler.cpp:8:0:
../../../dist/include/nsNetUtil.h:800:1: note: nsresult NS_NewStreamLoader(nsIStreamLoader**, nsIStreamLoaderObserver*)
../../../dist/include/nsNetUtil.h:800:1: note:   candidate expects 2 arguments, 4 provided
../../../dist/include/nsNetUtil.h:854:1: note: nsresult NS_NewStreamLoader(nsIStreamLoader**, nsIURI*, nsIStreamLoaderObserver*, nsINode*, nsSecurityFlags, nsContentPolicyType, nsISupports*, nsILoadGroup*, nsIInterfaceRequestor*, nsLoadFlags, nsIURI*)
../../../dist/include/nsNetUtil.h:854:1: note:   candidate expects 11 arguments, 4 provided
../../../dist/include/nsNetUtil.h:882:1: note: nsresult NS_NewStreamLoader(nsIStreamLoader**, nsIURI*, nsIStreamLoaderObserver*, nsIPrincipal*, nsSecurityFlags, nsContentPolicyType, nsISupports*, nsILoadGroup*, nsIInterfaceRequestor*, nsLoadFlags, nsIURI*)
../../../dist/include/nsNetUtil.h:882:1: note:   candidate expects 11 arguments, 4 provided
make[4]: *** [nsAbContentHandler.o] Error 1
make[4]: Leaving directory `/builds/slave/c-cen-t-lnx/build/objdir/mailnews/addrbook/src'
make[3]: *** [mailnews/addrbook/src/target] Error 2
make[3]: *** Waiting for unfinished jobs....

Might have something to do with https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=4120e1cbb5b4

but not too sure.

It's a recent bustage (22nd September).

Comment 1

[Philip Chee]

> Might have something to do with https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=4120e1cbb5b4

Merged into mozilla-central:
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=4120e1cbb5b4

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

That is most definitely the case, because we changed the signature of NS_NewStreamLoader:
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsNetUtil.h#816
so it can't be called from here:
http://mxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsAbContentHandler.cpp#155

Pulling comm-central/ now.

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

I am not sure how important that is as the moment, but in case we need a quick fix for the problem, we would have to update the arguments for NewStreamLoader [1]:

> nsCOMPtr<nsIPrincipal> nullPrincipal =
>   do_CreateInstance("@mozilla.org/nullprincipal;1", &rv);
> NS_ENSURE_SUCCESS(rv, rv);
>
> rv = NS_NewStreamLoader(getter_AddRefs(streamLoader),
>                        uri,
>                        this,
>                        nullPrincipal,
>                        nsILoadInfo::SEC_NORMAL,
>                        nsIContentPolicy::TYPE_OTHER,
>                        aWindowContext);

to call the following function [2].
                    
[1] http://mxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsAbContentHandler.cpp#155
[2] http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsNetUtil.h#881

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

Attachment: bug_1071497_update_newstreamloader_callsites_for_seamonkey.patch

This patch compiles and should work correctly, it will get a little bitroted once we remove nsIChannelpolicy argument from the API, which is about to land tonight [1].

I don't know who is the right reviewer for this, but it can definitely be used by developers as an interim patch.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1041180

Comment 5

[Robert Kaiser]

Comment on attachment 8494076 [details] [diff] [review]
bug_1071497_update_newstreamloader_callsites_for_seamonkey.patch

I'd guess one of Mark or Neil should be able to do the review here.

Comment 6

[[e-mail]]

Comment on attachment 8494076 [details] [diff] [review]
bug_1071497_update_newstreamloader_callsites_for_seamonkey.patch

Thanks for the patch! Can you tell me what the point of the nsIPrincipal* parameter is?

Comment 7

[Christoph Kerschbaumer [:ckerschb]]

(In reply to [e-mail] from comment #6)
> Comment on attachment 8494076 [details] [diff] [review]
> bug_1071497_update_newstreamloader_callsites_for_seamonkey.patch
> 
> Thanks for the patch! Can you tell me what the point of the nsIPrincipal*
> parameter is?

Currently, security checks are done before a channel is created, usually by calling NS_CheckContentLoadPolicy, like e.g. here in nsDocument:
  http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#1301

We are about to attach a loadInfo-object to every channel at channel-creation time, where the principal in that loadInfo-object is the requesting principal:
  http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsILoadInfo.idl#57

The next step of that approach will be to move security checks to asyncOpen where we then consume the principal set in the loadInfo. In case where we are not completely sure what the requestingPrincipal is, we currently use the nullPrincipal to be over-conservativ and deal with finding the accurate requestingPrincipal at a later time.
If you happen to know what principal we should use for the cases in the patch, please let us know and we can update that.

Comment 8

[[e-mail]]

(In reply to Christoph Kerschbaumer from comment #7)
> The next step of that approach will be to move security checks to asyncOpen
> where we then consume the principal set in the loadInfo. In case where we
> are not completely sure what the requestingPrincipal is, we currently use
> the nullPrincipal to be over-conservativ and deal with finding the accurate
> requestingPrincipal at a later time.
> If you happen to know what principal we should use for the cases in the
> patch, please let us know and we can update that.

A lot of this stuff doesn't make sense here because we're not dealing with web pages. I don't think we asyncOpen the imap mock channel so that's not an issue. I believe the URL fetcher is used for message attachments; I don't know whether the null principal will have file system permissions. As for the v-card handler that could potentially use the principal from the channel it just cancelled.

Comment 9

[Mark Banner (:standard8)]

Comment on attachment 8494076 [details] [diff] [review]
bug_1071497_update_newstreamloader_callsites_for_seamonkey.patch

Cancelling request as Neil's dealing with this.

Comment 11

[Magnus Melin [:mkmelin]]

Any update on this? We're busted for almost a week now.

Comment 12

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Magnus Melin from comment #11)
> Any update on this? We're busted for almost a week now.

I provided a patch, but from now on it's not very high up in my priority list anymore. Can someone else take it from here?

Comment 13

[[e-mail]]

Comment on attachment 8494076 [details] [diff] [review]
bug_1071497_update_newstreamloader_callsites_for_seamonkey.patch

Well, I guess things seem to work with the null principal for now...

Comment 14

[Joshua Cranmer [:jcranmer]]

https://hg.mozilla.org/comm-central/rev/4823bbd4a723