[Edbrowse-dev] Maybe do more with strings, maybe do everything with strings

[Edbrowse-dev] Maybe do more with strings, maybe do everything with strings

[Karl Dahlke]

When I first create the js runtime context,
and when I first create a window to go with the html page,
there are quite a few variables and functions that I set up within js itself,
only because it was easier to do it that way.
Look for the word initScript in jsdom.c.
And I likely could have put more stuff in there.
This raises some questions.

Are all the variables and functions that I made in that manner
protected from gc?
Is that a method that works?

Could it be used more often, and would that be easier and safer,
mostly safer, than what we are doing now?

Example: the function establish_property_string, which puts a string beneath
an object.
This is in jsloc.c.
What if it looked like this instead.

establish_property_string(const char *this_obj, const char *name, const char *value)

this_obj is the full name of the object,
"document.forms.foo.bar"
name and value are as they are today.
The function is then a silly wrapper.

{
char delim = '"'; // string delimiter
// you may need to switch delim to '\'' if value contains quotes.
// If value contains both quotes and apostrophes I'm not sure what to do.
string smallScript =this_obj + "." + name + " = " +
delim + valu + delim;
    JS_EvaluateScript(jcx, jwin, smallScript,
       "establish_property_string", 1, &rval);
}

That last line being replaced with whatever the new call is to
run the js engine on a string.

Looks easy; easier than what we're doing -
except we would have to maintain string pointers instead of object pointers,
even outside of js*.c,
possibly changing stuff in other files.
Might be worth stepping back a bit and see if this is a better approach.
It would almost surely be safer once complete,
since everything is done in their world, playing by their rules.

Karl Dahlke

Re: [Edbrowse-dev] Maybe do more with strings, maybe do everything with strings

[Adam Thompson]

On Sun, Jan 05, 2014 at 10:34:26AM -0500, Karl Dahlke wrote:
> When I first create the js runtime context,
> and when I first create a window to go with the html page,
> there are quite a few variables and functions that I set up within js itself,
> only because it was easier to do it that way.
> Look for the word initScript in jsdom.c.
> And I likely could have put more stuff in there.

Yeah I noticed that.

> This raises some questions.
> 
> Are all the variables and functions that I made in that manner
> protected from gc?

Yes as they're all attached to some sort of variable thus there's a reference to them within the js world.
> Is that a method that works?

Yes, in fact I think (haven't looked through the smjs source too closely)
that SpiderMonkey does something similar in places.
> 
> Could it be used more often, and would that be easier and safer,
> mostly safer, than what we are doing now?
> 
> Example: the function establish_property_string, which puts a string beneath
> an object.
> This is in jsloc.c.
> What if it looked like this instead.
> 
> establish_property_string(const char *this_obj, const char *name, const char *value)
> 
> this_obj is the full name of the object,
> "document.forms.foo.bar"
> name and value are as they are today.
> The function is then a silly wrapper.
> 
> {
> char delim = '"'; // string delimiter
> // you may need to switch delim to '\'' if value contains quotes.
> // If value contains both quotes and apostrophes I'm not sure what to do.
> string smallScript =this_obj + "." + name + " = " +
> delim + valu + delim;
>     JS_EvaluateScript(jcx, jwin, smallScript,
>        "establish_property_string", 1, &rval);
> }
> 
> That last line being replaced with whatever the new call is to
> run the js engine on a string.
> 
> Looks easy; easier than what we're doing -
> except we would have to maintain string pointers instead of object pointers,
> even outside of js*.c,
> possibly changing stuff in other files.
> Might be worth stepping back a bit and see if this is a better approach.
> It would almost surely be safer once complete,
> since everything is done in their world, playing by their rules.

Maybe but there'll be some things we couldn't do,
and as long as we correctly use the GC api everything *should* be fine.
It's just going to take a bit more rewriting to use the GC correctly.
Basicly I'd try and keep things in native code as otherwise we end up with many
c -> javascript -> c switches which is going to become a real pain.
It's just a case of working out how to properly encapsulate this c++ stuff from
the C code whilst playing nicely with the GC.

Also, do you know why the javascript context creation code is ran even when js is disabled?
I only noticed this when testing my version of edbrowse as I wanted to check if
I'd inadvertantly broken something somewhere else in all the git fun we were
having so I tried browsing a page I know contains no javascript with javascript
disabled and it still segfaulted in the javaCreatesContext function.
Surely, if javascript is disabled it shouldn't need to create the context at all?

Cheers,
Adam.