Breaking the grip JS has on the DOM

We want to change the grip JS has on the DOM and on XUL. We will do this in 2 steps:

• Change the framework to be language neutral - https://bugzilla.mozilla.org/show_bug.cgi?id=255942
• Create a Python implementation.

Ideally, the first step could be done without consideration for the second, in the assumption at the implementation should be truly language neutral. However, this first real implementation is likely to impact the design decisions made, so there will be some iteration involved

Original specification - stage 1

This is the high-level task list as specified at the start of the project:

• Extend nsScriptLoader using the XPCOM category manager to handle arbitrary <script type="...">
• MIME types, loading extension component mapped by MIME type through a category
• Abstract and multiplex nsIScriptContext, generalizing it (changing its IID of course) away from the JS API, making a nsIJavaScriptContext for JS and an nsIPythonContext for Python, fixing various places that assume nsIScriptContext "does JS"
• Fix default script language selection and event handlers, which are script-language-typed by the selected default, so that you can write Python event handlers.

High-level design decisions

Decisions made/ratified by Brendan etc:

• No sharing of language namespaces. Only the "global DOM namespace" (ie, the nsIScriptGlobalObject) will be shared.

Identified task list

These are the tasks identified during the analysis and implementation phases of the project.

Overview

The existing nsIScriptContext interface will remain tied to a specific language. The "void *" params in its interface will remain. This means that a "void *" and a suitable nsIScriptContext must always be treated as a pair (ie, given just a "void *", there is no way to determine an appropriate nsIScriptContext suitable for it - although "assume JS" is likely to remain for existing code that does exactly this)

nsIScriptContext will grow new methods relating to:

• language specific cleanup and "default language context" type code. For example, nsGlobalWindow.cpp has a number of calls to ::JS_ClearScope/::JS_ClearWatchPointsForObject etc - these need to be hidden behind one of the interfaces.
• The "WrapNative" process.

The existing nsIScriptGlobalObject interface will move towards a model where there is a global script context per language. GetGlobalJSObject and GetContext would be deprecated, with a new method allowing the desired language to be specified.

Some concept of a "language ID" will need to be invented. enum/char */atom?

The 'context stack' will need to be enhanced to allow each language to have their own implementation for pushing and poping context. Thus, when the DOM requires an item on or off the context stack, each language will be called once to do its own thing.

nsDOMClassInfo needs to be addressed - presumably its functionality is necessary for other languages - but it is heavily JS specific.

Below are specific implementation notes:

nsIScriptContext

• Existing JSObject replaced with void

• Need a "WrapNative" type function

• ExecuteScript - param 2 changes from "void *aScopeObject" to "nsIScriptGlobalObject *aScopeObject". JS impl fetches underlying JSObject.

• FinalizeClasses method - JS does the ClearScope/ClearWatchpointsForObject/ClearRegExpStatistics?

• Some kind of "SetProperty" function - as needed by nsGlobalWindow - "arguments", "navigator" etc. http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#871

nsIScriptGlobalObject / nsGlobalWindow

http://lxr.mozilla.org/seamonkey/source/dom/public/nsIScriptGlobalObject.h

nsGlobalWindow is the main implemention of nsIScriptGlobalObject

• nsIScriptGlobalObject probably needs to remain a single object (ie, not per language). It will move towards keeping a list of "IScriptContext *ctx, void *global" items, one for each language. New method:

 nsresult GetLanguageContext( [in] language_id language, [out] nsIScriptContext **retLangContext, [out]void **retLangGlobal);

mJSObject and mContext will both be dropped in favour of the list. The concept of a single context/global will be deprecated - callers will be encouraged to use the new method. GetContext()/GetGlobalJSObject() remain for b/w compat. They are equivilent to "GetLanguageContext('js', ...)"

• New method to set and get "properties" - nsGlobalWindow does this for JS. Setting a property should presumably set it in all languages (via the global attached to the context). Getting is tricker - what if the property is in a different language? Or in multiple languages?
  • Properties set include "arguments" and "navigator". Presumably other code also sets additional properties?
  • Properties fetched seem arbitrary.

• "Arguments" will need to be specified in a language neutral way. Maybe array of nsVariants?

• Serializing scripts?

• CompileScript:

  nsXulElement.  Line 3666:
  // XXXbe violate nsIScriptContext layering because its version parameter
  // is mis-typed as const char * 
  sets mJSObject

Context Stack

Existing nsIJSContextStack "@mozilla.org/js/xpc/ContextStack;1" service is replaced with language generic ContextStack. This is almost identical to the JS version, but all functions accept a 'language_id' param, to indicate which language they are interested in. Existing 'js' specific context stack could be re-implemented using the new one.

Probably need a new interface for each language to do their thing. The DOM will simply ask for a new context - something must do the delegation to the languages.

What about http://lxr.mozilla.org/seamonkey/source/dom/public/nsIScriptContext.h#356 - it checks flags. Will there be flags for a single stack entry, or flags for each language in a single stack entry, or both?

JS_GetContextPrivate ???

nsScriptLoader

• nsScriptLoader's interface is language neutral. Theoretically only the implementation need change.

nsDOMClassInfo

Some of this will need to be generalized for use by multiple languages. Specifically, the "tables" of interfaces and access to the extended type information would be unmaintainable across multiple languages.

nsXULPrototypeScript

Change JSObject *mJSObject -> void *mScriptObject, and add new nsIScriptContext reference.

Event listeners

http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventListenerManager.cpp#1160

Changes required:

• AddScriptEventListener() needs a "language_id" passed in
• 'context' still comes from ScriptGlobal
• Use of "@mozilla.org/js/xpc/ContextStack;1" needs to be abstracted into the nsIScript interfaces.

Exceptions

Exceptions should be chained across languages. This should just mean diligent use of nsIExceptionService?

Identified list of things we will *not* do

• We will make no attempt to have abstract the security interfaces - Python has no concept of "untrusted code". This means Python will be restricted to running from trusted XUL.
• Principals (obviously we must not change existing semantics, but Python will ignore them.)
• Allowing a language version to be specified.

Stuff Mark still needs to grok

• Still a little gray on the relationship between a JSContext, a "scope" and a "global".
  • JSContext a DOM specific concept, so script_language -> C++ -> script_language preserves the state of the globals (correct?)
  • What is in a "context" beyond the global object?

• WrapNative and what it really means to this

• What exactly does nsDOMClassInfo do??? How can we factor it?

• nsBindingManager - very JS specific and not using nsIScript interfaces

• Need to understand the desired 'undefined' semantics for the return value. Python's builtin None is closer to a JS null, so may not be suitable for 'undefined'. However, a simple 'return' will return None.

• Timeouts look tricky.

• Events look tricky

Random Notes

Some notes about existing callers of certain interfaces.

nsDOMParser:

• Gets "native call context" to end up with nsIScriptContext - apparently all just to get the script URI nsDocShell
  • http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsDOMParser.cpp#476
  • Will need to know the language_id that should process the data from the stream
• Security related functions

nsXMLHttpRequest.cpp

* GetCurrentContext uses the JS ContextStack.

mozXMLTermUtils.cpp:

 * mozXMLTermUtils::ExecuteScript called nsIScriptContext::ExecuteScript -      but with NULL "void *" pointers.  Needs to have nsIScriptContext passed?

nsScriptSecurityManager.cpp/nsSecurityManagerFactory.cpp:

• Almost all functions convert a JSContext to an nsIScriptContext. Most just use to GetGlobalObject - GetPrincipalAndFrame has JS assumptions
• nsSecurityNameSet::InitializeNameSet - Lots of JS specific code.

docshell/base/nsDocShell.cpp: 1 use nsDocShell::CheckLoadingPermissions() - use of JF ContextStack to fetch nsIScriptContext - just to GetGlobalObject

embedding/components/windowwatcher/src/nsWWJSUtils.cpp

• Converts JSContext to nsIScriptContext. Mainly for GetGlobalObject, but nsIScriptGlobalObject *nsWWJSUtils::GetStaticScriptGlobal has JS deps.

embedding/components/windowwatcher/src/nsWindowWatcher.cpp:

   JSObject * nsWindowWatcher::GetWindowScriptObject
       not used???

   nsWindowWatcher::AttachArguments
   AddSupportsTojsvals
       2038       rv = xpc->WrapNative(cx, ::JS_GetGlobalObject(cx), data,
       2039                            *iid, getter_AddRefs(wrapper));
 

content/base/src/nsContentUtils.cpp:

   Convert nsIScriptContext -> JS Context

content/base/src/nsDocument.cpp:

   Convert nsIScriptContext -> JS Context -> CanRunScripts
   (can CanRunScripts take an nsIScriptContext?)

nsRange:

   nsRange::CreateContextualFragment - seems to push/pop a JS Context?

content/base/src/nsScriptLoader.cpp:

       nsScriptLoader::ProcessScriptElement
           Does the actual loading of the stream.
       EvaluateScript calls nsIScriptContext->EvaluateScript - with most args

content/events/src/nsEventListenerManager.cpp:

   Quite JS specific
   

content/xbl/src/ nsXBLBinding

   ::JSSetPrototype for a new context?

nsXBLDocumentInfo:

 implementation of nsIScriptGlobalObject.
  JSObject *mJSObject;    // XXX JS language rabies bigotry badness
  mJSObject = ::JS_NewObject - abstraction?

nsXBLProtoImpl:

 Lots of JS Specific code.
 Fairly generic compile function: http://lxr.mozilla.org/seamonkey/source/content/xbl/src/nsXBLProtoImpl.cpp#192

content/xul: nsXULElement

   event handlers remain JS specific
   serialization too

nsXULDocument:

   Calls ExecuteScript with mScriptGlobalObject->GetGlobalJSObject() as an arg
    case nsXULPrototypeNode::eType_Script: {
      else if (scriptproto->mJSObject) {
                    // An inline script
                    rv = ExecuteScript(scriptproto->mJSObject);
                    if (NS_FAILED(rv)) return rv;
                }

   XUL Script cache

dom/src/base/nsDOMClassInfo.cpp

 Lots of JS - dynamic DOM not exposed by XPCOM class info?
 

dom/src/base/nsGlobalWindow.cpp

   JS specific "scope" code
    nsIScriptContext *currentCX = nsJSUtils::GetDynamicScriptContext(cx);
    argv handling
    Creating a window - calls WindowWatcher::OpenWindowJS
    

dom/src/events/nsJSEventListener.cpp:

layout/generic/nsObjectFrame.cpp

xpfe/appshell/src/nsAppShellService.cpp

plugins/activex/embedding/crypto: ignoring for now.