Right now if we want to turn on/off features defined a new interface, yet implemented in existing class, we need something like http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMClassInfo.cpp?rev=3f82f25d7334&mark=2373-2386#2368 But that doesn't scale. I think we could add something like DOM_CLASSINFO_MAP_ENTRY_CONDITIONAL(interface, condition) (Note, this bug is *not* about hiding the interfaces itself. That is being fixed elsewhere. javascript: DesktopNotification should not work, but it does atm)

I don't think an interface per feature is going to scale either. I'd been imagining something like interface nsIDOMWindow { [pref(dom.enable.webperf)] readonly attribute nsIDOMPerformance mozPerformance; };

There are cases when the whole classes need to be removed. E.g. navigation timing spec (http://www.w3.org/TR/navigation-timing) defines 3 classes--Performance, PerformanceTiming and PerformanceNavigation which should not be visible to javascript if related feature is turned off. Does this bug cover such cases?

(In reply to comment #1) > interface nsIDOMWindow { > [pref(dom.enable.webperf)] readonly attribute nsIDOMPerformance > mozPerformance; > }; This would be great, indeed, although it is possible that we'll need also conditions on interface entries. What I don't want us to do is something similar to webkit. Some .idl files are starting to look really bad there with all the #ifdefs.

webidl!