executeScript(): KJS problem with "this" object

Peter Kelly pmk@kde.org
Tue, 4 Feb 2003 20:58:40 +1030 (CST)


This looks like the way to go I think. The spec doesn't mention situations 
like this when you're executing code from the host environment and need 
to provide a this object, so as far as I can see this doesn't conflict 
with it.

On Mon, 3 Feb 2003, David Faure wrote:

> KHTMLPart::executeScript takes a DOM::Node parameter, which I understand as
> "make this the 'this object'". Koos Vriezen (which I just subscribed here) 
> uses it for LiveConnect stuff, where the "this" object should be the 
> HTMLAppletElementImpl, for instance.
> However he reported to me that this doesn't set the "this object" from it.
> 
> This is because InterpreterImp::evaluate creates a ContextImp with code type
> of GlobalCode, which _ignores_ the "thisV" parameter, and sets "thisVal" to
> be the global object instead (internal.cpp:705).
> 
> This patch fixes it. However I guess it's against the ECMA spec?
> 
> --- internal.cpp	23 Jan 2003 21:53:56 -0000	1.142
> +++ internal.cpp	2 Feb 2003 23:24:15 -0000
> @@ -702,7 +702,10 @@ ContextImp::ContextImp(Object &glob, Exe
>      case GlobalCode:
>        scope = List();
>        scope.append(glob);
> -      thisVal = Object(static_cast<ObjectImp*>(glob.imp()));
> +      if ( thisV.isNull() )
> +        thisVal = Object(static_cast<ObjectImp*>(glob.imp()));
> +      else
> +        thisVal = thisV;
>        break;
>      case FunctionCode:
>      case AnonymousCode:
> 
> [ It appears to me that none of the other types of code would do
> (there is no activation object, and we want new variables to go into
> the global object, so this is not FunctionCode/AnonymousCode;
> EvalCode ignores thisV too, when a calling context is set. So the
> only solution seems to be GlobalCode using thisV, as done below...) ]
> 
> Can someone shed some light on this?
> 
> PS: the reason it works for event listeners, is that kjs_events.cpp directly
> calls function.call( exec, thisObj, args ) :) No special codeType there, it's
> reusing the globalExec of the interpreter..... Hmm, this means that new vars
> go to the global object instead of going to the activation object of the
> function? :}
> 
> 

-- 
Peter Kelly
pmk@kde.org