[webkit-dev] JavascriptCore questions

[Edward Rowe]

Hi Webkit folks -

I'm Ed Rowe, and I work on the Apollo project at Apollo. I've got some
questions about JavascriptCore that I'm hoping to get answered. The
background is that I am trying to write a full-featured subclass of
JSObject that forwards to an object in a different script engine
(Flash's ActionScript in this case) and vice versa. Doing this correctly
requires me to understand a number of details, some of which I admit
seem somewhat pedantic. I have read all of the code for JSValue,
JSObject, most of the binding code, etc. in order to figure things out
on my own to the degree that it is possible. Now for the questions:

 

Interpreters, ExecStates, Binding
---------------------------------
- ConvertValueToNPVariant() and convertValueToObjcValue(), which are
used in the plugin interface binding code, both contain special logic
that basically says "if wrapping up a window object, store the
RootObject associated with the window object in the wrapper rather than
the current RootObject". Can you tell me the purpose of this logic? I
have theories, but nothing definitive.

- The JavaScriptObject struct contains pointers to RootObjects. I may be
missing something, but it appears to me that a JavaScriptObject struct
can outlive the RootObjects that it points at, which could lead to the
use of freed memory. Can this happen?

- What are the rules around exceptions in the ExecState retrieved from
Interpreter::globalExec()? It appears that most of the uses of it assume
that there is no exception already in the ExecState when it is retrieved
and clear any exception and before returning ensure that it contains no
exception. Is this correct? 

- When a plugin is unloaded, what happens if there are existing
RuntimeObjectImp instances that reference objects provided by the
plugin? Is there logic to prevent a plugin from being unloaded if there
are extant objects that it has provided? I haven't been able to find any
code that ensures this.

- There are a variety of places where
exec->dynamicInterpreter()->globalObject() is called. For example, this
happens in FunctionProtoFunc::callAsFunction() to handle the apply case
when the this arg is NULL. In such cases, is it correct to use the
global obj from the current ExecState's Interpreter as opposed to the
global object at the root of the scope chain? ECMA 262 section 15.3.4.4
seems somewhat ambiguous on this subject, but my reading leads me to
think that it would be more correct to pull from the scope chain.



JSObject and JSValue
--------------------
- Can you confirm that NULL is never an immediate JSValue and can be
used to mean "no JSValue"?

- Is it legal for JSObject::hasProperty(), JSObject::canPut(), or
JSObject::deleteProperty()  to set an exception in the passed ExecState?
I cannot find any current code doing this, but I'm not sure if it is a
case I need to handle or not.

- Is it legal for JSObject::get() to ever return NULL?  I cannot find
any current code doing this, but I'm not sure if it is a case I need to
handle or not.

- Is it legal to set an exception in the passed ExecState in
PropertySlot's GetValueFunc? I can't find any precedent in the code for
a propgetter (or get itself for that matter) to throw. 

- Is it legal for JSObject::call() to ever return NULL?  I cannot find
any current code doing this, but I'm not sure if it is a case I need to
handle or not.

- Is the result of JSValue::type() expected to be immutable for a given
JSValue instance? That is, can a particular instance return different
types at different times?

- Are the results of JSObject::implementsConstruct(),
JSObject::implementsCall(), and JSObject::implementsHasInstance()
expected to be immutable for a given JSObject instance? That is, can a
particular instance return different values at different times?

- The default implementation of JSObject::defaultValue() and
JSObject::toPrimitive() can return an Error object if an exception
occurs. This would seem to violate ECMA 262 sections 8.6.2.6 and 9.1
which state that defaultvalue() and toPrimitive() return non-Object
types. Looking at some of the callers of toPrimitive(), it appears that
some are not prepared to handle getting an object back. I'll file this
as a bug if you guys like.

- Neither JSObject::propertyIsEnumerable() nor
JSObject::getPropertyAttributes() are virtual, making it impossible for
a subclass to override the default behavior. Any objection to making
propertyIsEnumerable() virtual, and making getPropertyAttributes()
private?

 

Thanks in advance for the help! 

Ed