[Edbrowse-dev] Parallel versions of js access functions

[Edbrowse-dev] Parallel versions of js access functions

[Karl Dahlke]

As you know, ebjs.c has functions that act as a layer between edbrowse and the js world.
They send requests to edbrowse-js and receive responses,
and pass them back to the calling function.
Here is the flow of events.
Parse the html text courtesy of tidy,
build our own tree of nodes,
decorate that tree by calling functions in ebjs.c
to instantiate objects and create properties etc,
then, eventually, render the tree.
All good, but as mentioned before, we may need to generate and decorate a
subtree from inside javascript at the moment foo.innerHTML is set to a string.
so the same procedure takes place in edbrowse-js under the control of a setter.
To that end, I now have native copies of many of these layer functions.
Most of these functions were there already, I just had to do a little trickery
so they have the same names as those in ebjs.c.
What's the point?
All the code that decorates the html tree can be shared.
It calls set_property_string(inputTag, "value", val)
for example, and in edbrowse,
when decorating the nodes of the original web page,
that function passes the request over to edbrowse-js and receives an ack.
Inside the edbrowse process, when parsing the html assigned to
foo.innerHTML, the function simply runs native code to make the assignment.

This approach assumes we are going to leave the two processes separate,
as they already are.
That allows for separate layer functions with the same arguments and returns.
That's probably the best path.

Course there's more to do here.
render.c has to be separated into two files,
render.c and decorate.c
The first is true to its name, rendering a tree for the text buffer,
the second generates and decorates a tree with js objects.
The second would be included in both processes,
like stringfile.c etc.
html-tidy.c would also be shared in both processes.
And of course both would have to link with the tidy library.
So code might be moving around a bit.
A commit may say I inserted and deleted 500 lines,
but it's not really that drastic; just rearranging things.

Kevin do you think document.write is similar to innerHTML
in that it is suppose to take effect immediately?
html is parsed and js objects created,
and made available by the next line of the running javascript?
I actually hope the answer is yes,
cause if we're going to go through all this redesign
to make it happen for innerHTML, then document.write
may as well go along for the ride.

Karl Dahlke

Re: [Edbrowse-dev] Parallel versions of js access functions

[Kevin Carhart]

This is terrific.  I'm relieved to hear that it
may be less bad than originally thought.

I had a thought which may be moot now but here
is a graf about it just in case.  I was wondering
about JS-based parsing from a pluggable piece of
JS that is a utility function providing a service.
Leave it on the JS side.  At the time of innerHTML,
who knows, the script could have another 800 steps
ahead, which will obliterate the tags in the
innerHTML long before the next time the user is
working with edbrowse buffers.   The tags in the
innerHTML could be inherently intermediate.
Just a way of manifesting an assert() of some
concept, which populates a boolean, which the
code uses for something else.  edbrowse
rendering isn't going to be
enlisted for a while yet, so I thought maybe
on balance, while it would be yet another component,
maybe it would be less of redesign for JS to
call a JS-based parser and keep working.
The moment of the side effects call remains
the time and place when we consolidate what
edbrowse needs to process.

Is my impression even accurate in the
first place?  And even if so, in the
intervening time I think you've solved it!

> Kevin do you think document.write is similar to innerHTML
> in that it is suppose to take effect immediately?
> html is parsed and js objects created,
> and made available by the next line of the running javascript?

I am almost positive that is true.  I found the following
in the bowels of the yellowpages.com code without needing
to look very hard.
frameDoc.open();
frameDoc.write(div.innerHTML);
var $bingImg=$(frameDoc).find("#minimap > img");
...
frameDoc.close()

I'm making some assumptions that this cherry-picked
piece of JS is relevant, but I think it represents
what you're asking about and if it happens to be
used in my guinea pig website, it is probably
something that gets relied on and used
all over the place.

K

[Edbrowse-dev] Parallel versions of js access functions

[Karl Dahlke]

> The tags in the innerHTML could be inherently intermediate.

Yes they could, and in that case the side effects would
eventually create them and delete them,
or perhaps create them but never link them into the tree and thus never rendered.
That's not great but not awful,
and probably not worth all the software it would take
to detect and manage this situation.
Disconnected parts will all clean up during unbrowse
as part of garbage collection.
I'm inclined to just let it ride.

So very well, document.write will process via the same mechanism
as innerHTML, under the aegis of the innerHTML setter function
in native js, at the moment of execution.
The real trick is passing the created subtree back to edbrowse,
which I have some ideas on, that are not fully formed yet.
Once reconstituted on our side, the subtree can be pasted into our primary tree,
ready for rendering.

Karl Dahlke