Adding a method to HTMLCollection.prototype should allow that method to be called on all HTMLCollections, like document.images or document.frames: HTMLCollection.prototype.test = function() { alert("test"); } document.images.test(); (document.images.constructor == HTMLCollection, so that's not the problem) I wouldn't have noticed, if there wasn't bug 14869, which makes document.getElementsByTagName return an HTMLCollection.

So all that's going on here is that HTMLCollection.prototype is not on the proto chain of, say, document.images... The reason, I assume is that HTMLCollection is a proto for things that use the HTMLCollection classinfo. document.images uses the ContentList classinfo, which goes by the HTMLCollection name, but isn't an HTMLCollection.

Confirmed. This problem just bit me. I was trying to extend the HTMLCollection prototype object for the purpose of changing the new .children property in Firefox 3.1. HTMLCollection can be extended in Opera, WebKit and Konqueror. No issues there.

Peter, do new list bindings fix this? Or do you need to do the nodelist/htmlcollection split first?

The problem with images is that we have two DOMCIs for HTMLCollection, and whichever is defined first wins. For example starting with images, |HTMLCollection.prototype.test = function() { alert("test"); } document.images.test();| would work, but then |document.createElement("form").elements.test()| would fail. And vice versa. That's fixed with the new DOM bindings. Also, |document.createElement("select").options.test();| now works due to the new DOM bindings. I'm going to mark this fixed, the nodelist/htmlcollection split will just allow us to return the right type of object wherever we currently return a nsContentList (which sort of ends up as an HTMLCollection in JS).