We have eval() which dynamically compiles code into the current scope and runs it with the current security principal. We have evalInSandbox which compiles code in an container and runs it with a security principal given at sandbox construction. The missing combination is an eval which compiles code into a given scope and runs it under the security principal of that scope. For an inner nsIDOMWindow 'win', evalInGlobalScope(str, win) should give an XPCSafeJSObjectWrapper around an object that is precisely as one would get by running win.eval(str) with the principal of 'win'. This would allow Firebug's command line to be implemented very simply. It would also allow extension code to generally avoid eval() with extension (system) principal. See also http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/9d6404c7c940097b# If possible, then for jsdIStackframe.scope 'scope', then evalInGlobalScope(str, scope) would be supported. If not we may want to call the function evalInDOMWindow(). The option filename and line numbers of evalInSandbox() would nice.
can I get a rationale for this blocking nomination?
The short answer is "no", I was trying to express "gee if we had this in the 3.7 plan we could plan to work on the Firebug parts". But it's not so we won't.
Just want to add, that one Firebug issue related to this is http://code.google.com/p/fbug/issues/detail?id=1472. Sebastian
I expect the fix for bug 785174 should serve here, as well. If not, please un-dup and explain.