331023 - Cleanup of IDL files; fixing type inconsistencies

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Johnny Accot]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060318 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060318 Firefox/1.6a1

There are a few inconsistencies in Mozilla's IDL files with regard to type and interface definitions.  This includes:

- Types that are declared in different ways in different IDL files
- Interfaces that are declared but never defined (at the IDL level)
- Interfaces that have no scriptable/noscript flag

In this bug, I am trying to list such inconsistencies.

I need to mention that some "problems" I report here might be intentional or even features.  I list them here hoping it could help make the IDL file set sounder.  I hope at least a few fixes in the attached patch will be useful...

Reproducible: Always

Actual Results:  
N/A

Expected Results:  
(At least what *I* would expect)

- Types should be consistent across IDL files.
- Interfaces should have either a scriptable or noscript tag.
- Types that are declared as interfaces should have a definition as an interface or be declared as native types.

I made a list of types/interfaces that pose problem, and I have a patch that fixes some of them.

1. Interfaces that are declared but never defined

I found 39 interfaces (after the patch is applied) that are declared (forward declaration) but never defined:

 DOMException
 LSException
 RangeException
 XPathException
 jsdIPC
 nsIAccessibleEventListener
 nsIChannelSecurityInfo
 nsICmdLineService
 nsIContent
 nsIDOMCSSStyleRuleCollection
 nsIDOMSVGViewSpec
 nsIDocument
 nsIEditingShell
 nsIFilePath
 nsIFrame
 nsIFrameSelection
 nsIJVMPlugin
 nsILDAPURL
 nsILayoutHistoryState
 nsIMdbEnv
 nsIMdbRow
 nsIMdbTable
 nsIObjectFrame
 nsIPresShell
 nsIRenderingContext
 nsIScriptContext
 nsIScriptElement
 nsIScriptGlobalObject
 nsIScrollbarMediator
 nsISecureEnv
 nsIServiceManagerObsolete
 nsISocketEventSink
 nsIUnicodeDecoder
 nsIUnicodeEncoder
 nsIWidget
 nsIWordBreaker
 nsObjectFrame
 nsPresContext
 nsSVGPathData

Maybe some declarations are not necessary anymore.  Maybe some could be declared as native types.  I don't know enough about how these types are used to be able to know what is the best option.  But as a developer, when I see a forward declaration, I do expect to see the actual declaration at some point.

2. Type that have different declarations in different files

A few types that are used very often are defined sometimes as interface, sometimes as native, sometimes as typedef.  For example, nscolor can be declared either as:

native nscolor(nscolor);  // in nsISVGGeometrySource.idl and nsISVGGradient.idl
typedef PRUint32 nscolor; // in nsISVGRendererCanvas.idl

There is also:

[ptr] native nsPresContext(nsPresContext); // in nsIDocShell.idl
interface nsPresContext; // in nsINativeScrollbar.idl and 4 other files

and:

[ptr] native nsIFrame(nsIFrame); // in nsISelectionPrivate.idl
interface nsIFrame; // in nsIAccessibilityService.idl and 4 other files

There are other such inconsistencies that the patch attempts to fix.

3. An interface should be marked as scriptable or noscript.

xpidl explicitly requires that an interface that derives from a non-scriptable interface should also be non-scriptable.  When interface A has non-scriptable methods that are not marked as noscript, interface A should itself be marked as noscript.  But if interface B inherits from A and needs to be scriptable, xpidl will complain that B should be noscript too.  One way to bypass xpidl's complaint is to neither mark interface A as scriptable or noscript.  (A more elegant method would be to mark the non-scriptable methods as noscript and the interface as scriptable.)  So there are a few interfaces that have only a uuid property, like:

[uuid(31431440-f1ce-11d2-985a-006008962422)]
interface nsIXPCSecurityManager : nsISupports
{...};

It is a bit disorienting for a developer to see such an interface.  Personally, I don't know if it is scriptable or noscript by default.  A "grep '\[uuid\(.*\)\]' *.idl | wc -l" shows that 95 interfaces have neither a scriptable or noscript tag.  In the patch, I fixed the interfaces that have scriptable descendants by adding "scriptable" to their properties.

Finally, there are a few tags here and there that don't follow the general IDL rules that are used in other files.  For example, there is only one attribute in the whole IDL file set that is marked as notxpcom:

nsIClassInfo.idl:    [notxpcom] readonly attribute nsCID classIDNoAlloc;

Similarly, there are some unusual tags in some interface declaration which I couldn't figure out if they are still used:

% grep '\[.*uuid(.*)\]' *.idl | grep -v '\[scriptable, *uuid' | grep -v '\[uuid' | grep -v '\[noscript, *uuid'
nsIDOMEventListener.idl:[scriptable, function, uuid(df31c120-ded6-11d1-bd85-00805f8ae3f4)]
nsIDOMNodeFilter.idl:[scriptable, function, uuid(e4723748-1dd1-11b2-8ee6-866a532a6237)]
nsIDOMUserDataHandler.idl:[scriptable, function, uuid(91afebdd-a201-4db0-b728-9d59580f0cfd)]
nsIDOMXPathNSResolver.idl:[scriptable, function, uuid(75506f83-b504-11d5-a7f2-ca108ab8b6fc)]
nsIFactory.idl:[scriptable, object, uuid(00000001-0000-0000-c000-000000000046)]
nsISchemaLoader.idl:[scriptable, function, uuid(8d9aa9ce-e191-11d8-9f31-000393b6661a)]
nsIXMLHttpRequest.idl:[scriptable, function, uuid(6459B7CE-6B57-4934-A0AF-0133BA6F9085)]
rdfITripleVisitor.idl:[scriptable, function, uuid(aafea151-c271-4505-9978-a100d292800c)]

The "object" tag in nsIFactory doesn't even seem to be handled by xpidl.  The "function" tag is handled and saved in the xpt file, but I couldn't figure out what it means, so I just mention it.

I can spend more time on that stuff if somebody is interested and tells me which option is good (eg. native or interface) for which type, etc.

Comment 1

[Johnny Accot]

Attachment: Fix for some type inconsistencies in Mozilla's IDL files

Comment 2

[timeless]

Comment on attachment 215576 [details] [diff] [review]
Fix for some type inconsistencies in Mozilla's IDL files

let's start with the basics. posting one single patch spanning the world will not work. each microcosm has its own rulers, its own rules and its own decission making process. i'm writing a long detailed comment in this bug. so please don't do anything until i finish.

Comment 3

[timeless]

so.

first. scriptable and noscript aren't really complementary.
second. forward declaring an interface pointer and declaring something as a native aren't complementary either.
third. some forward declarations are for screwy W3 DOM statements.

e.g. DOMException

is forward declared to allow for raises() which we ignore. As it happens.  DOMException in our world is nsIDOMDOMException (and similarly for similar W3 Exception creatures).

some are really just errors and can be killed, jsdIPC was removed by http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/jsd/idl/jsdIDebuggerService.idl&rev=1.17 as part of bug 115695. And I'll post a patch at some point to remove it.

nsIAccessibleEventListener was removed by
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/accessible/src/base/nsRootAccessible.h&rev=1.33 as part of bug 193802. And I'll post a patch at some point to remove it.

nsICertSelect seems like a stillborn rough interface proposal which was probably never used afaik. (it references nsIChannelSecurityInfo which you noted.) we can ask kaie about it.

nsICmdLineService exists at:
http://lxr.mozilla.org/mozilla/source/xpfe/components/startup/public/nsICmdLineService.idl

whlie c++ can #include some file that causes the full interface to appear, it doesn't always need to. so there's no reason to force c++ to do so. The generated .h files do indeed have class statements (they don't really have many choices). so this seems like a silly case to flag.

wrt nsIContent, it's true that some things use native statements, but that makes things messier and actually *hurts* the ability of things to use connectivity because then they don't know that there's an nsISupports relationship (including addref/release). it also means that a system that wants to dynamically QI to nsIContent (or whatever) given something else can't. personally i'd rather fix nsIXULTemplateBuilder and nsIEditor not to use native ptr statements.

wrt CSSStyleRuleCollection from domstubs.idl which isn't implemented, it looks like it was at least a proposal.
http://lightning.prohosting.com/~dhtmlf/CSSMediaRule.htm

personally, i'd rather not go changing domstubs for some level of purity about future interfaces that we don't yet have. if we eventually get them, i'd rather blame be attributed to the original planner (jst in that case).

SVGViewSpec / nsIDOMSVGViewSpec seem to be something form w3 dom that we just don't implement:
http://xmlgraphics.apache.org/batik/javadoc/org/w3c/dom/svg/SVGViewSpec.html

removing it is just as bad as any of the other dom removals.

The same comments about nsIContent apply to nsIDocument. And please don't go around adding [noscript] tags just because you can't use them today from a script. ideally at some point i'll be able to (i have patches that let me do it).

nsIEditingShell
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Feditor%2Fcomposer%2Fpublic%2FnsIEditingSession.idl&rev=1.2
was removed by smfr although nsIEditorDocShell wasn't updated. this needs to be fixed.

nsIFilePath wasn't even an interface or anything in m10
http://landfill.mozilla.org/mxr-test/m10/search?string=nsIFilePath
so that should definitely go away :).

nsIFrame is going to eventually get itself out of interfaces on its own, so pushing it here is imo a bad thing. let someone who knows what's going on kill it.
http://landfill.mozilla.org/mxr-test/seamonkey/search?string=interface+nsIFrame&find=idl%24&filter=nsIFrame%5Cb

hopefully the same applies to nsIFrameSelection
http://landfill.mozilla.org/mxr-test/seamonkey/search?string=interface+nsIFrameSelection&find=idl%24&filter=nsIFrameSelection%5Cb

nsIJVMPlugin interacts with foreign libraries, so changing it in any way would be very very very risky. just let it be. eventually sun wants to replace OJI w/ JEA.

could you please explain why nsILDAPURL is on your list? afaik bz wouldn't like the fact that one module is extending a different module's interface.

nsILayoutHistoryState
personally, i'd like to see that converted to an idl file with a native ref for  nsPresState

nsIMdbEnv and probably nsIMdbRow and nsIMdbTable could probably be rewritten as idl interfaces files if you can figure out how to convert all the mork encapsulation into corresponding idl types. of course people are trying to kill mork as they add sqllite. so it's probably a waste of everyone's time to bother.

nsIClassInfo is frozen. it can't be changed. don't bother thinking about it or any other interface that is frozen (or deprecated which you should read as frozen since we promise not to change deprecated interfaces).

the function annotation should mean that you can instead pass a javascript function and have it wrapped in an object which has the indicated method forward to the javascript function.

i'm not sure about the object annotation and i'll look at a later time.

nsIObjectFrame's idl consumer indicates that it's eventually going away. let someone else kill it. bug 90268

nsIPresShell
nsIAccessibleRetrieval is listed as UNDER_REVIEW but there's no way it's freezing with that interface
xmlterm should be treated as an external dependency. unless you want to adopt the module, you should leave it alone.

nsIRenderingContext
its consumer nsISVGRenderer already lists it as noscript. see earlier comments.

nsIScriptContext/nsIScriptContextOwner
nsIScriptElement/nsIScriptLoader+nsIScriptLoaderObserver 
nsIScriptGlobalObject/nsIScriptContextOwner
 please just leave them alone, they're not hurting anyone and they make reading the code easier. (idl is much easier to read than the generated output).

nsIScrollbarMediator
afaik it's .h because of PRInt32& aNewIndex, and personally i'd like to see it converted to a .idl. but you'd have to get widget signoff.

nsISecureEnv
see nsIJVMPlugin comments

nsIServiceManagerObsolete/nsILegacyPluginWrapperOS2+nsIClassicPluginFactory 
this is legacy support and it interacts with foreign modules. please leave it alone.

nsISocketEventSink
appears to have been introduced unused (ala nsICertSelect), we can ask
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Fnetwerk%2Fbase%2Fpublic%2FnsISocketTransport.idl&rev=1.15
as part of bug 176919. And I'll post a patch at some point to remove it.

 nsIUnicodeDecoder
 nsIUnicodeEncoder
 nsIWordBreaker
i believe i already filed a bug to make these scriptable.

 nsIWidget
was added unused to nsIRollupListener
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Fwidget%2Fpublic%2FnsIRollupListener.idl&rev=1.2
as part of bug 33733. And I'll post a patch at some point to remove it.
(it'd also be nice if the interface was changed to use boolean should...() instead of void Should...(out PRBool...))

its use in nsIWindowMediator is too old to touch, that interface should probably be considered frozen. note that the interface does include noscript annotations.

nsObjectFrame
nsIAccessibilityService could use nsISupports as it does for the others. but of course these are probably frames and perhaps accessible shouldn't be using them....

nsPresContext
nsISelectElement
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Fcontent%2Fhtml%2Fcontent%2Fpublic%2FnsISelectElement.idl&rev=1.3
its use was removed in bug 108309. And I'll post a patch at some point to remove it.

nsINativeScrollbar
appears to have been introduced unused (ala nsICertSelect),
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Fwidget%2Fpublic%2FnsINativeScrollbar.idl&rev=1.1
as part of bug 121440. And I'll post a patch at some point to remove it.

I'm not sure about the SVG consumers, but i'd rather let someone internal to layout file a bug asking that it be removed. at least one of the methods has an // XXX do we need this. I'd appreciate a reference to a bug number about that question.

nsISVGRendererPathGeometry {...  void flatten(out nsSVGPathData)...}
well, at the very least that should be nsSVGPathData flatten(), and given that it *isn't* an interface, it should be changed to use native.

Comment 4

[timeless]

Attachment: remove unused nsIAccessibleEventListener from nsRootAccessible

Comment 5

[timeless]

Attachment: remove unused nsPresContext from nsISelectElement

Comment 6

[timeless]

Attachment: remove unused nsIEditingShell from nsIEditingSession

Comment 7

[timeless]

Attachment: remove unused jsdIPC from jsdIDebuggerService

Comment 8

[timeless]

Attachment: remove unused nsISocketEventSink from nsISocketTransport

Comment 9

[timeless]

Attachment: remove unused nsPresContext from nsINativeScrollbar and nsIWidget from nsIRollupListener

Comment 10

[timeless]

Comment on attachment 215576 [details] [diff] [review]
Fix for some type inconsistencies in Mozilla's IDL files

If you're going to make interfaces scriptable, then at the very least please change methods from
void Thiscase();

to
void thiscase();

But again, any such changes really need serious review from module owners. and ideally a chance for other people to give feedback. and changes should be grouped into distinct reviewable patches with descriptions about what they're changing and review requests made of individual module owners (although i can help you with that part).

>Index: layout/svg/renderer/public/nsISVGGeometrySource.idl
>-native nscolor(nscolor);
>+typedef PRUint32 nscolor;

wow.

Comment 11

[[e-mail]]

Comment on attachment 215624 [details] [diff] [review]
remove unused nsPresContext from nsINativeScrollbar and nsIWidget from nsIRollupListener

>-interface nsPresContext;
> interface nsIFrame;
Nit: nsIFrame isn't used either.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

-  void Create(inout int argc, inout string argv);
+  void Create(inout long argc, inout string argv);

this is not right... the author of this function apparently just used the first thing that gave them the desired C++ signature. in reality, argv is an (in) array of strings.

>I found 39 interfaces (after the patch is applied) that are declared (forward
>declaration) but never defined:

many of these are defined in C++ header files rather than IDL. not all of them should probably be converted to native() declarations, because it might be a good idea to convert them to IDL at some point, and it'd be nice not having to change references to them in other IDL files.

Comment 13

[Johnny Accot]

First, thank you for the thorough reply.  With regard to the patch, I want to mention again that "I don't know what I am doing" :-)  Even though I'm pretty good at XPCOM programming, I don't know the internals of the Mozilla framework enough to know what makes sense or not when it comes to low-level data structures or calls.  But I didn't invent anything either: among the different choices of definition of types, I picked the one that looked more convenient.  That applies to the nscolor typedef.  I saw that definition in nsISVGRendererCanvas.idl and used it.

To give a bit of context, I am working on a tool that performs IDL statistics.  And that tool chokes each time it sees a type that was defined before and then defined in a different way. So despite my likely poor choices in the patch, the good news is that I can guarantee that these are the only inconsistencies in all the IDL files (that is the ones installed is ${idldir}, not all the ones in the source tree).

Finally the patch was not meant to be applied as is.  It was meant to prevent my tool from choking, first, and then help Mozilla developers pinpoint possible problems in the IDL files.

(In reply to comment #3)
> 
> first. scriptable and noscript aren't really complementary.

Ah. Ok.  But still, as an outsider, I am quite confused when I see an interface with [uuid(...)] only.  I have no idea if I can use it in a script.  Sorry for my [noscript] frenzy :-)

> second. forward declaring an interface pointer and declaring something as a
> native aren't complementary either.

I understand, but it is (was) still confusing when something is declared as an interface but does not have an "I" in its name (the DOM exceptions, nsObjectFrame, nsPresContext, and nsSVGPathData), in which case one wonders if the person didn't mean to use a native type, or when something has an "I" in its name and is declared as native.  It's good if nsObjectFrame, nsPresContext, and nsSVGPathData get fixed already.

With regard to the native-type declarations, maybe it is a good idea, for reference, to list the types that involve interfaces:

nsIAppShell.idl:            [ptr] native nsIEventQueue(nsIEventQueue);
nsIAppShell.idl:            [ptr] native UndefinednsIWidget(nsIWidget);
nsIBaseWindow.idl:          [ptr] native nsIWidget(nsIWidget);
nsIDocShell.idl:            [ptr] native nsIPresShell(nsIPresShell);
nsISelectionPrivate.idl:    [ptr] native nsIFrame(nsIFrame);
nsISelectionPrivate.idl:    [ptr] native nsIPresShell(nsIPresShell);
nsIRDFXMLSink.idl:          [ptr] native nsIAtomPtr(nsIAtom);
nsIContentViewer.idl:       [ptr] native nsIWidgetPtr(nsIWidget);
nsIContentViewer.idl:       [ptr] native nsIDeviceContextPtr(nsIDeviceContext);
nsIEditor.idl:              [ptr] native nsIPresShellPtr(nsIPresShell);
nsIEditor.idl:              [ptr] native nsIContentPtr(nsIContent);
nsIEditorIMESupport.idl:    [ptr] native nsIPrivateTextRangeListPtr(nsIPrivateTextRangeList);
nsIEditorStyleSheets.idl:   [ptr] native nsICSSStyleSheet(nsICSSStyleSheet);
nsIScriptableRegion.idl:    [ptr] native nsIRegion(nsIRegion);
nsIXULTemplateBuilder.idl:  [ptr] native nsIContent_ptr(nsIContent);
nsIPluginHost.idl:          [ref] native nsIStreamListenerRef(nsIStreamListener *);
nsIPluginInstanceOwner.idl: [ref] native nsIPluginInstanceRef(nsIPluginInstance *);

Would it be sound to suggest that if an interface is actually defined in an IDL file (eg. nsIEventQueue and nsIAtom), that they should be moved to a "interface <interface_name>;" declaration; and if the interface is defined in C++ only, then it should be declared as 'native <interface_name>Ptr(<interface_name>);"?  This convention would make it easy for developers to know right away, with a simple grep command, which interface is defined at the IDL level or in C++.  This goes against the suggestion in comment #3 and #12, but I must admit I never realized nsIWidget or nsIContent didn't have an IDL spec...  If there was a hint in the name that says it's defined in C++, it might help.  If one day somebody wants to move such an interface to IDL, it is trivial to find which interfaces could be converted.

UndefinednsIWidget is unused; the last two declarations seem weird, but I guess that's legacy too.

> third. some forward declarations are for screwy W3 DOM statements.
> 
> e.g. DOMException
> 
> is forward declared to allow for raises() which we ignore. As it happens. 
> DOMException in our world is nsIDOMDOMException (and similarly for similar W3
> Exception creatures).

I see.  Would it make sense to add:

%{C++
typedef nsIDOMDOMException DOMException;
typedef nsIDOMLSException LSException;
typedef nsIDOMRangeException RangeException;
typedef nsIDOMXPathException XPathException;
typedef nsIDOMSVGException SVGException;
%}

somewhere?  Not very useful, but people would have a chance to know they are the same by looking at the IDL files.

If they are the same thing, maybe it would make sense to change all "nsIDOMDOMException" to "DOMException" in the nsIDOMSVG*.idl too.

> nsICmdLineService exists at:
> http://lxr.mozilla.org/mozilla/source/xpfe/components/startup/public/nsICmdLineService.idl
> [...]
> could you please explain why nsILDAPURL is on your list? afaik bz wouldn't like
> the fact that one module is extending a different module's interface.

Oops.  In fact, I ran my tool in the installed ${idldir}.  For both nsICmdLineService and nsILDAPURL, it seems as if they are not installed but some interfaces that reference them are, which is why they appear undefined for me.  I don't know if that comes from my mozconfig options or not.  I use Xulrunner from the trunk BTW.

My guess is that Mozilla switched from the interfaces in xpfe/components/startup/ to the ones in toolkit/components/startup/ and toolkit/components/commandlines/ at some point, and the old API is not installed anymore.  But, anyway, it looks like the new (toolkit) nsIAppStartup.idl and nsINativeAppSupport.idl declare nsICmdLineService but don't use it.  The only interface that still uses it is nsIProfileInternal.  I'll submit a patch.

As for nsILDAPURL, in my configuration, nsILDAPSyncQuery.idl is installed and references nsILDAPURL, but nsILDAPURL.idl is not installed.  Maybe an extra option would fix that.

> nsIScrollbarMediator
> afaik it's .h because of PRInt32& aNewIndex, and personally i'd like to see it
> converted to a .idl. but you'd have to get widget signoff.

I tried to submit a patch to add nsIScrollbarMediator.idl:

https://bugzilla.mozilla.org/show_bug.cgi?id=331102

(maybe I should have submitted it here; oh well)

> nsISVGRendererPathGeometry {...  void flatten(out nsSVGPathData)...}
> well, at the very least that should be nsSVGPathData flatten(), and given that
> it *isn't* an interface, it should be changed to use native.

I'll try to add a patch for that too.

Thanks again for your comments and your patience.  As you may have guessed, I am not very familiar with Bugzilla (yet).

Comment 14

[ken smith]

March 28/06 installed Lightning in most recent Tbird. It replaced Mozilla Calendar, dumped my wired mouse which was subsequently identified as new hardware, didn't dump my wireless mouse, wouldn't let me type anythisn in Thunderbird, Firefox 1.5x or Open Office (text).

I was able to uninstall it using extension manager and had to reinstall Mozilla Calendar and reboot twice to get everything back to normal.

System
AMD k7
O/S Widows XP Pro
Memory 384 meg

And Lightening appeared but didn't work.

Hope this helps

Ken Smith

Comment 15

[Kai Engert (:KaiE:)]

removing the unused idl nsICertSelect file seems fine to me.

Comment 16

[timeless]

Attachment: treat nsIContent as an interface per my suggestion in comment 3

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 221121 [details] [diff] [review]
treat nsIContent as an interface per my suggestion in comment 3

Frankly, we should just fix nsIEditor to use an nsIDOMNode, imo...

I'm not really sure what the reasons for this change are.  Doesn't "intgeface" as used in our IDL mean "IDL-defined interface"?

Comment 18

[timeless]

Comment on attachment 215619 [details] [diff] [review]
remove unused nsIAccessibleEventListener from nsRootAccessible

mozilla/accessible/src/base/nsRootAccessible.h 	1.56

Comment 19

[timeless]

Comment on attachment 215620 [details] [diff] [review]
remove unused nsPresContext from nsISelectElement

mozilla/content/html/content/public/nsISelectElement.idl 	1.12

Comment 20

[timeless]

Comment on attachment 215621 [details] [diff] [review]
remove unused nsIEditingShell from nsIEditingSession

mozilla/editor/composer/public/nsIEditingSession.idl 	1.12

Comment 21

[timeless]

Comment on attachment 215622 [details] [diff] [review]
remove unused jsdIPC from jsdIDebuggerService

mozilla/js/jsd/idl/jsdIDebuggerService.idl 	1.33

Comment 22

[timeless]

Comment on attachment 215623 [details] [diff] [review]
remove unused nsISocketEventSink from nsISocketTransport

mozilla/netwerk/base/public/nsISocketTransport.idl 	1.24

Comment 23

[timeless]

Comment on attachment 215624 [details] [diff] [review]
remove unused nsPresContext from nsINativeScrollbar and nsIWidget from nsIRollupListener

mozilla/widget/public/nsIRollupListener.idl 	1.5
mozilla/widget/public/nsINativeScrollbar.idl 	1.4

Comment 24

[timeless]

(In reply to comment #15)
mozilla/security/manager/ssl/public/Attic/nsICertSelect.idl	 1.4

Comment 25

[[e-mail]]

Comment on attachment 221121 [details] [diff] [review]
treat nsIContent as an interface per my suggestion in comment 3

I think nsIContent should clearly look native.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 221121 [details] [diff] [review]
treat nsIContent as an interface per my suggestion in comment 3

sr-; I'd like to see answers to my questions.

Comment 27

[timeless]

> we should just fix nsIEditor to use an nsIDOMNode

Sure, but i wasn't signing up for random major work in components

> Doesn't "interface" as used in our IDL mean "IDL-defined interface"?

No, it means "derives from nsISupports" which nsIContent does, albeit ~10 links away.

Comment 28

[Boris Zbarsky [:bzbarsky]]

> Sure, but i wasn't signing up for random major work in components

That's fine, but just file a bug for that work instead of hacking around it...  or is the current setup really hurting someone Right Now?

Comment 29

[timeless]

Comment on attachment 221121 [details] [diff] [review]
treat nsIContent as an interface per my suggestion in comment 3

filed bug 343397.

i think the only hurry is that in a few days I might cease to exist.

Comment 30

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.