As you know, we use the pointer to the object as the link between that object in the js world and the corresponding html tag in the edbrowse world.
We did this in Mozilla, and naturally carried it across to duktape.
The documentation guarantees these pointers are valid, as long as the object is not garbage collected away.
We've come to learn that's a mighty big if.
I wrote a fair amount of code to make sure we weren't diddling with an object that was thrown away, because you get a seg fault if you do. Boom!
But then there's a bigger problem.
I'm sure this was present in mozilla, but we never got far enough down the road to see it.
tag1 links to object1 by pointer1, and javascript removes object1, and it is thrown away, and creates object2, which happens to use the same pointer1.
It passes pointer1 back to edbrowse, which already has this recorded in tag1.
So now tag1 is linked to object2, which may be a form instead of a div, may have different number of children, etc etc.
It is potentially bad, with unpredictable behavior, and nearly impossible to reproduce.
We went down the pointer path because neither engine gives you an unambiguous handle to the object.
So now I'm writing more code to know that object2 is new, and even if it uses pointer1, which we have in our registry, we should delete that tag and make a new one,
and I already broke edbrowse in a mysterious way, and it's just badbadbad.
So I'm thinking instead, why don't we create our own IDs.
Just a sequence number that we put on every object we care about, and an array to map back from sequence number to the object.
A bit of overhead, but no crashes if we accidentally reference an object that is gone, and no ambiguity - one object per id.
Change jsobjtype from voidd * to int, and systemically change everything else accordingly.
A fair chunk of work, but might be worth it.
I really don't have a better alternative right now. What do you think?

Karl Dahlke