628590 - nsIProtocolProxyService2 should have new iid due to changes in parent interface nsIProtocolProxyService

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[palo misik]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: 

In gecko2.0 was added new attribute into nsIProtocolProxyService (readonly attribute unsigned long proxyConfigType;). This change caused that nsIProtocolProxyService2 (in gecko 192 and gecko 20) aren't binary compatible because this change shifts methods in vfptr of nsIProtocolProxyService2 by one.
To distinguish between these two interfaces is required new iid of nsIProtocolProxyService2.

Reproducible: Always

Comment 1

[palo misik]

Attachment: Changed iid of nsIProtocolProxyService2 due to changes in nsIProtocolProxyService

Comment 2

[Boris Zbarsky [:bzbarsky]]

Ugh.  Unfortunately, at this point I don't think we want to take this sort of change for 2.0...  :(

Comment 3

[Josh Matthews [:jdm]]

Does anything still need to happen here, given that we presumably shipped without the IID change?

Comment 4

[palo misik]

Of course, check in is needed.
It can be fixed in FF5.

Comment 5

[Boris Zbarsky [:bzbarsky]]

The question is whether the IID change is worth it at this point.  It probably can't hurt to do it prophylactically (though doing it for Fx5 would need to happen pretty darned soon).

Comment 6

[Benjamin Smedberg]

We should not do this for FF5 now. I'm happy for us to bump the IID for FF6, but I also don't think it's a big benefit since you have to recompile binaries for each major version now anyway.

Comment 7

[palo misik]

(In reply to comment #5)
> The question is whether the IID change is worth it at this point.  It probably
> can't hurt to do it prophylactically (though doing it for Fx5 would need to
> happen pretty darned soon).

It was rejected for FF4 and it seems now also for FF5.

The magnificence of distinct iids for interfaces is that you can do a simple generic and fast code for detection a initialization of interfaces wrappers based on tables (so my extension was initialized in fast way and doesn't slow down start-up).
for (int i=0; i<aInterfaceCount; ++i){
    if ( piid->Equals( pTable->iid ) ){
        aActiveInterface = pTable;
	  return NS_OK;
    }
    pTable = ....;
    ...
}
Now I have to change code that doesn't fit the rule of distinct iids in way which will also check and parse Platform version which will slowdown start-up and increase binary size of extension.

[pseudo-code]
If (piid->Equals(nsIProtocolProxyService_Gecko191))
{
...
}
If (piid->Equals(nsIProtocolProxyService_Gecko192))
nsCOMPtr<nsIXULAppInfo> appInfo = do_GetService(XULAPPINFO_SERVICE_CONTRACTID, &rv);
	if (NULL == appInfo)
	{
		nsCString aPlatformVersion;
		rv = appInfo->GetPlatformVersion( aPlatformVersion );
if ( aPlatformVersion == 1.9.2.x)
 		{ ...}
            Else if ( aPlatformVersion == 2.0.0.x)
 		{ ...}
            Else if ( aPlatformVersion == 2.1.0.x)
 		{ ...}
      }
...
}

Generally iid change should affect mainly extension developers not FF. This is because you rebuild entire FF. Possible problem could be if there is some compare in JavaScript code with hard-coded iid value.

I really do not understand what you fear of changing iids if interface was really changed. I really think it is better to find out that some initialization failed then at run-time(in debugger) find out that is called different method then it was expected to be called.

The worst thing that can happen is that something stop working and it can point out to code that didn't expected change in interface or badly written code.

Comment 8

[Patrick McManus [:mcmanus]]

this can ride along with 769764 which updates iids in both idls

Comment 9

[Patrick McManus [:mcmanus]]

fixed by 769764 
https://hg.mozilla.org/mozilla-central/rev/828f91de7143