Dan Veditz, Mike Shaver, Mitch Stoltz, and I had a conf call earlier today to discuss the various "capabilities" models we have floating around, and to determine if there's room for consolodation (there is). Existing models - CAPS - uses the prefs insfrastructure to make client "capability" based decisions. Generally encompasses two areas: granular JS execution policy (enable XPConnect in JS for example, don't execute JS at all for example), and URI scheme based load enable/disable (web based URI schemes (HTTP) can't access file based schemes (FILE)). nsIWebBrowserSetup - leverages various underlying models (CAPS being one of them) to enable/disable various active content (JS, plugins, redirects, etc) on a per-top-level-window basis (not global). nsIWebFilter - fires callbacks from the necko load level (single choke point) to allow/disallow a load based on the URI string. Can be used to block loads, of any protocol, w/ the word "sex" in them for example. nsIURIStreamListener - fires a callback (OnStartURIOpen()) from the URILoader (which loads url bar, click, and image lib level URLs - "top level loads") to determine whether or not the load should even be attempted. This one, like nsIWebFilter, only has the URI string to make a decision on. nsIContentPolicy - not completely hooked up yet. implementors of this iface register w/ the category manager to be called when multiple choke points are hit (frame level loads for out-of-line (<img src= for example) content as an example). The callbacks include a DOMElement which provide rich context for making a go/no-go decision for load time, as well as process time (running JS for example). We touched on accessibility needs/requirements as best we could w/ out representation, and believe their needs can be addressed w/ the current plan. The various models have advantages over one another, yet share, at least, the load/no-load capability. -CAPS provides JS execution granularity that no-one else does. -nsIWebBrowserSetup provides per-top-level window granularity which no-one else does. -nsIWebFilter provides a *single* choke point which no-one else does. -nsIURIContentListner provides a top level load choke point. -nsIContentPolicy provides rich nsIDOMElements in its callbacks, and multiple choke points, which no-one else does. Current thinking - nsIContentPolicy, being a global callback mechanism, w/ rich nsIDOMElement context, is the most flexible and generic. It puts the onus on the nsIContentPolicy callback implementor to determine when/how it will decide to block something, which is what we want. If we couple CAPS into the process() method of nsIContentPolicy, we can push CAPS down a level and say that granular JS capabilities can be addressed via nsIContentPolicy. (mitch/shaver) We can add two new "types" of load to nsIContentPolicy, to replace nsIURIContentListener::OnStartURILoad(), and nsIWebFilter callbacks. That would kill those two in favor of nsIContentPolicy. (valeski/mscott/gagan/dougt/shaver) That leaves nsIWebBrowserSetup. We would need to bake per-top-level-window nsIContentPolicy querying into the nsIContentPolicy model, so we could maintain the per-top-level-settings. (shaver) The top three things can be done fairly independently, and each is a step in unifying our "capability" story. Shaver's putting some docs together about how nsIContentPolicy is actually used, and how it might incorporate per-top-level-window policies, and CAPS. The basic use idea is that you impl nsIContentPolicy, and register for its category callback. You can then, via the callbacks you impl'd, dicatate what gets loaded and what can "run." See the interface for the info you have at your disposal to make the decision. Jud
