I found interfaces that should have changed iid because they are changed
indirectly - by inheritance. I compared gecko 1.8.1 and 1.9.2.
In all following interfaces is changed parent interface but derived
interface is not changed and iid of derived interface isn't changed.
For c++ extension developer that supports multiple version of gecko this
cause quite bizarre crashes because methods in vfptr are shifted
(because added /removed methods in parent interface) so you call
different method convinced that you call correct method because iid of
interface you used your extension know.
Here are affected interfaces:
nsIDOMXULControlElement
nsIDOMXULElement
nsIDOMXULTextBoxElement
nsIDOMXULMenuListElement
nsIDOMXULMultiSelectControlElement
nsIDOMXULLabeledControlElement
nsIDOMXULCheckboxElement
nsIDOMXULButtonElement
nsIDOMXULTreeElement
nsIDOMXULSelectControlItemElement
nsIDOMXULPopupElement
nsIDOMXULDescriptionElement
nsIDOMXULLabelElement
nsIDOMXULImageElement
nsIDOMXULMenuListElement
nsIDOMXULMultiSelectControlElement
nsIExtendedExpatSink
nsINativeTreeView
nsIASN1Tree
nsIAuthPromptWrapper
nsIToolkitChromeRegistry
nsITransfer
nsPIDNSService
nsIToolkitChromeRegistry
nsIAutoCompleteBaseResult
nsIAutoCompleteMdbResult
nsIAutoCompleteMdbResult2
There is a question whether they should be changed in 1.9.2 or just
since 1.9.3.
https://bugzilla.mozilla.org/show_bug.cgi?id=530505
PM-
> There is a question whether they should be changed in 1.9.2 or just
> since 1.9.3.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=530505
I do not think we should change the IIDs at this point, given that we've
already released the beta versions that addon developers are supposed to use
for compatibility checking. There is a simple-enough workaround (QI-check
the changed base interface) for those cases where it actually matters. It's
good to have this list, though, and we should probably publish it somewhere
as a warning for addon authors using these interfaces from binary code.
--BDS