As seen in bug 655517.

Want to fix? ;)

I can, but that doesn't mean I know what effect it will have.

Comment on attachment 532460 [details] [diff] [review] Patch v1 Hmm. Well, neither do I. The patch as given will cause duplicate DOM_CLASSINFO_MAP_ENTRY(nsIDOMDocument) for a bunch of document classes and will cause others to contain both DOM_CLASSINFO_MAP_ENTRY(nsIDOMDocument) _and_ DOM_CLASSINFO_MAP_ENTRY(nsIDOMHTMLDocument). I presume this last is why the entry is not in DOM_CLASSINFO_DOCUMENT_MAP_ENTRIES to start with, but I'm not sure whether the duplication is a problem.

(In reply to comment #3) > The patch as given will cause duplicate > DOM_CLASSINFO_MAP_ENTRY(nsIDOMDocument) for a bunch of document classes Please don't do that. > will cause others to contain both DOM_CLASSINFO_MAP_ENTRY(nsIDOMDocument) > _and_ DOM_CLASSINFO_MAP_ENTRY(nsIDOMHTMLDocument). Harmless but unneeded, code that uses this walks the interface chain of every interface in the array anyway, so nsIDOMDocument is hit as part of nsIDOMHTMLDocument What are we trying to fix exactly?

Comment on attachment 532460 [details] [diff] [review] Patch v1 You should at least remove nsIDOMDocument from any class that uses DOM_CLASSINFO_DOCUMENT_MAP_ENTRIES.

What I'm trying to fix is Olli's comment in bug 655517. If nothing is wrong here, please close this bug.

I was complaining about the inconsistency in nsDOMClassInfo. In some cases nsIDOMDocument is there, some cases not.

Where "there"?

Let's kill DOMCI instead.