I'm not planning to work on this right now, however: I think it would be a good long-term goal to remove nsIInterfaceRequestor. I believe its existence was basically a mistake. It was a convenient way to add a "getter" (with bad ergonomics) to something without modifying a (potentially binary-frozen) interface. But in the absence of frozen interfaces, I don't think it should exist anymore. Getting rid of it is somewhat difficult, though. Basically, each use of it would need to be converted to a getter on some interface the object implements. So for each use, the usage pattern would need to be audited, and appropriate changes made. Thus this bug is a meta-bug.

I think doing this is tied up in our addon story, because something like: // XXX: _getBrowserWindowForContentWindow and _getBrowserForContentWindow // were taken from browser/components/feeds/WebContentConverter. _getBrowserWindowForContentWindow: function(aContentWindow) { return aContentWindow.QueryInterface(Ci.nsIInterfaceRequestor) .getInterface(Ci.nsIWebNavigation) .QueryInterface(Ci.nsIDocShellTreeItem) .rootTreeItem .QueryInterface(Ci.nsIInterfaceRequestor) .getInterface(Ci.nsIDOMWindow) .wrappedJSObject; }, is extremely common in our browser code, and probably equally pervasive in our addons. Maybe that's just proving the point that we should find better ways to expose things than QI/getInterface chains (which are expensive anyway).

Agreed that it's tied to addon api stability. I think that with this bug fixed, something like that should probably look like: return aContentWindow.webNavigation.rootTreeItem.window.wrappedJSObject; possibly with a few QueryInterface calls in the middle.

Since the goal is to get rid of XPCOM-using addons over the course of the next year (?), and this is clearly a longer-term problem, perhaps that doesn't matter so much.