[PATCH 7/8] jscript: Implement separate script dispatch objects for each named item.

[Jacek Caban]

On 21.02.2020 19:49, Gabriel Ivăncescu wrote:
> Hi Jacek,
>
> On 21/02/2020 19:31, Jacek Caban wrote:
>> On 21.02.2020 13:55, Gabriel Ivăncescu wrote:
>>> Hi Jacek,
>>>
>>> On 20/02/2020 22:41, Jacek Caban wrote:
>>>> Hi Gabriel,
>>>>
>>>> First of all, this patch breaks mshtml script tests. It's likely 
>>>> that it's mshtml's fault, but we need to get it working.
>>>>
>>>
>>> Ok I'll take a look into it, didn't know it could.
>>
>>
>> Yeah, mshtml is the main and most complex active script user we have 
>> in tree. It can host multiple script with in multiple languages, so 
>> vbscript can call jscript, etc. All script languages share global 
>> namespace and may call each other. This is done by mshtml window 
>> object exposing properties of all hosted script engines. To make it a 
>> bit more complicated, there may be multiple frames (like <frame> and 
>> <iframe> elements) and scripts in these don't share script engine nor 
>> global namespace with other frames but may access them using DOM API. 
>> The code doing that in mshtml could use some work, but I'm not sure 
>> if this part is responsible for the problem, only testing could tell.
>>
>>
>> On top of that native IE since version 9 rewrote JavaScript engine. 
>> In recent version, jscript.dll is not used for mshtml. To support new 
>> features that are present in native jscript.dll, we extended active 
>> script versioning API to add new flags that control those features. 
>> This is still work in progress. Quite a few additional APIs are 
>> implemented, but a lot more are missing. The main known problem is 
>> how objects are handling because. Making mshtml objects behave more 
>> like JavaScript objects needs a better mechanism than IDispatchEx. I 
>> have some ideas about that, but never had time to implement it.
>>
>>
>> Anyway, I'm saying that because what we observe in mshtml is not 
>> necessarily matching active script variant (because we know that 
>> native is not limited by active script). We have quite a few tests 
>> about how active scripts are handled in script.c, it should allow 
>> confirming here the problem is.
>>
>>
>
> Thanks, it appears that there's a corner case with 
> SCRIPTITEM_GLOBALMEMBERS and the script dispatch, and this applies to 
> both jscript and vbscript, so mshtml doesn't seem to be wrong here. I 
> will of course add tests to both of them to show this behavior.
>
> While investigating this I also found out another behavior for 
> SCRIPTITEM_CODEONLY (again for both jscript and vbscript), namely that 
> the 'this' or 'me' returns the item's disp, and only returns the 
> script_obj if the flag is set.
>
> I'll do some more testing just to make sure I'm not missing something, 
> but I have a general idea of how to fix both cleanly.


Good to hear it, thanks.


>>
>>>>
>>>>>       jsdisp_t *prototype;
>>>>>   @@ -433,6 +437,7 @@ struct _script_ctx_t {
>>>>>       DWORD last_match_length;
>>>>>         jsdisp_t *global;
>>>>> +    jsdisp_t *item_context;
>>>>
>>>>
>>>> Same here, do we really need it?
>>>>
>>>
>>> Probably not, but I'm not that familiar with the code. What's the 
>>> easiest or best way to retrieve it from the bytecode? From call_ctx? 
>>> Or perhaps from the ei? 
>>
>>
>> When you're in interpreter, yes. Otherwise, it depends. Once you get 
>> rid of variables I mentioned and start using context from bytecode, 
>> it should become clear what we need to worry about. I sense that the 
>> problematic areas will be where builtin functions need to parse source.
>>
>
> Right, currently I have it so the context from bytecode sets the 
> ei->named_item in exec_source at the start and also creates the script 
> dispatch on demand.
>
> The ei->named_item is also set before compiling the script in 
> ParseScriptText/ParseProcedureText, but it is automatically picked in 
> 'eval' though (which also needs compilation).


Let me explain problem with ei (where "ei" should really be something 
like caller_context after recent changes, but I didn't do renaming yet 
wanting to make sure that's how we want it first). It is set when we 
enter the script and shared by internal script calls as long as they 
don't leave or re-enter the script. So let's say we have contexts ctx1 
and ctx2, both exposing ctx_id property and a global variable get_ctx_id.

In side ctx1, we execute:

get_ctx_id = function() { return ctx_id; };

And now inside ctx2, we execute:

var x = get_ctx_id();

What will be the value of ctx_id? It's parsed in context of ctx1, so I'd 
expect it to be ctx1.ctx_id. But it was called by code inside ctx2 and 
we never left interpreter, so ei will still point to ctx2, so you may 
get ctx2.ctx_id.


That said, maybe there is some use for ei. But it's not generally what 
you need.


Jacek