Forking to add support for ObjectTemplate accessor or interceptor

[stroiman]

I had the crazy idea to build a headless browser in Go, so I need a JavaScript engine.

The DOM itself would be implemented as Go objects, and therefore, I need to expose those as JavaScript objects, which is apparently what the ObjectTemplate is meant for (based on about 5 minutes of research)

Unfortunately, the crucial parts for, setting accessors or interceptors is not implemented yet. At least as far as I can tell.

• https://v8.dev/docs/embed#accessors
• https://v8.dev/docs/embed#interceptors

I intend to work on these in a new fork. It appears that the groundwork is done, so adding this functionality shouldn't be too hard.

Unless work has commenced already on these features?

This seems to be the most up-to-date fork of the original project, which is why I use this as my starting point.

[stroiman]

While I'm at it, I may just as well add support for both, if I succeed with one.

[stroiman]

Hmmm, seems the documentation in the links does not appear to be current, so apparently not official documentation.

There is not a SetAccessor method, but there is a SetAccessorProperty, which I now have wrapped, and it compiles, but probably isn't working, as I haven't tried it.

[tommie]

Hey. Nice "little" project. :)

More than happy to accept patches, but having spent six months just getting the freaking auto-update workflow working smoothly, I'm a bit exhausted. :)

[stroiman]

No worries. That part pretty cool though, good work 👏

I was confused by the discrepancies in the interface. I found these docs for v8: https://v8docs.nodesource.com/
but not even the latest version was consistent with the header files in this project. I finally found this link: https://v8.github.io/api/head/ where the documentation is consistent with the header files in this project; e.g. SetAccessorProperty instead of SetAccessor, as well as some other changes.

I encountered more missing features, e.g. support for "external" values. So far, I've added support for that in a branch - https://github.com/stroiman/v8go/tree/external-support with two different variations, one that uses pointers, and one that uses interface{}. Don't know which is more useful; maybe both?

But at any rate, I have something that actually works; i.e., I can expose Go objects to JS.

But I'm still getting the v8 engine, e.g. relationship between ObjectTemplate and Object, and how I can create the proper JS objects; including the proper prototype chains; and how this codebase is wrapping it.

[stroiman]

My headless browser, btw, is in https://github.com/stroiman/go-dom

[tommie]

https://v8.github.io/api/head/ is the official documentation, linked from https://v8.dev/docs/api, so that's probably the best source, indeed.

I found the ObjectTemplate tricky to reason about. Most of the interesting functions are in its superclass, Template. Not sure I ever had t oset a prototype, but it's possible that's simply about assigning the prototype property.

[stroiman]

Thanks for the link, did get a lot of obsolete references from google search.

For my purpose, creating a headless browser for testing, I think the object template makes sense to use for creating the global object.

For each test I create, I would create a new v8 context with it's own Window - the global object in a browser. By using a template, I don't need to configure the global for each v8 context, just pass the template, and set the internal field pointing to the Go instance of that wraps a "window". And also all the members of the global object, i.e., all the classes; Document, HTMLElement, ...etc.

But it appears to be necessary when you want to use an "external", for example create a JavaScript wrapper for a native object. You need to set an "internal field" pointing to the object, and before you do that, you need to tell how many internal fields the object has by calling SetInternalFieldCount. And that function is only available on the template. Although I don't see why it couldn't be on Object also.

[stroiman]

Btw, I'm encountering a few more unsupported but necessary features, e.g FunctionTemplate::PrototypeTemplate, and FunctionTemplate::InstanceTemplate.

Btw, if you want to check out the have work in a branch external-support.

And now I think I need a Persistent. When I create an object in Go, and create a JS wrapper, I need to ensure it isn't garbage collected until both Go code and JavaScript code is done using it. As far as I can tell, the solution here is to use Persistent::MakeWeak where I provide a callback when it's ready for GC in JavaScript.

As I understand, the object needs to be pinned by a runtime.Pinner, and the callback should call Unpin. I'm not familiar with unsafe programming in Go, but I have used unmanaged languages before, e.g. C++ and Delphi (long time ago, I think it's managed to day, but it wasn't back then).

[tommie]

I don't have much to add, but Pinner is pretty new. The 1.21 release notes point to https://pkg.go.dev/cmd/cgo#hdr-Passing_pointers for additional information.

[stroiman]

btw, do you have any relation with, acquaintance, or had communication with @rogchap , who as I understand, wrote the majority of the code?

[tommie]

Not other than PRs. Not all were accepted. It seems abandoned, even though there are several users with commit rights.

See the links in the top of the README for my attempts to reach out. I'd be more than happy for them to take my PRs and build workflows, but don't have high hopes ATM.

[stroiman]

Hi again.

I tried to reach out to rogchap, but haven't heard back. Mostly from the intent of getting code feedback, or ask about some things I think look a little odd, or things I believe could be simplified.

Anyway, I've added quite a bit of functionality; but I haven't made any PRs yet, as the code is somewhat hacked, and I haven't written test for any of it. The code is only tested through my other project.

I'm mostly mentioning this, if you also are in the situation that you need any of this functionality, there's no reason to add it twice.

Or if in other ways, you need to extend the functionality; it would be nice at least to share experiences.

I think this is a complete list of extensions I've made (checking git log messages):

• Support for external values, i.e. storing a pointer in an v8 object, pointing to a native value
  • I abandoned that approach though, as you need to pin the values, so internally I give the objects an integer id, and store them in a map, and only store the id as an internal property.
• FunctionTemplate.Inherit. When a function template represents a class, the Inherit can be used to specify class inheritance
• Object.GetPrototype / SetPrototype
• ObjectTemplate.PrototypeTemplate
• ObjectTemplate.InstanceTemplate (I've named it GetInstanceTemplate, but InstanceTemplate is the V8 function name, so I should rename mine)
• ObjectTemplate.SetAccessorProperty - allow creating named property getters/setters on object templates.
• ObjectTemplate.SetIndexedHandler. Internally, there are two overloads of `SetHandler, one for named properties, and one for indexed. This implements indexed, but I have only implemented the getter. The handler takes 5 or 6 callbacks, I only support one yet.
  • Reuses code from FunctionTemplate to handle callbacks, it's not the right solution. I added another value to CallbackInfo, being the index; which is only used in this case, where the Args are not used.

I am currently working on tapping into console, allowing go code to intercept console.log and friends. I have a hook into go code right now, but I need to figure out some details.

But I also see some other issues I intend to address.

Callback handling, e.g. native functions, property handlers, etc.

Handling function callbacks does come with quite a bit of code; and to handle all features of both named and indexed property handlers, I think that will be 10 new kinds of callback; i.e., callback types with different signatures.

Then you have console message callback, and weak handle callbacks (when a v8 value is garbage collected)

I don't want to duplicate all the current callback handling code 10 times, so I'll probably look into how to simplify callback handling

Memory Management

It seems all Value objects keep a Global<Value> handle, that is placed in a large pool associated with the script context. These are relased when context is disposed, but for many of them, they are held too long in memory. That's not so much a problem for my intended use case, but probably something I'll look into.

While the object exposes a function to release the object, I think there are many objects that are held for too long.

[tommie]

You seem to have been busy. :) Good to hear about your progress.

I think this is a complete list of extensions I've made (checking git log messages):

The template functions do sound useful.

I think that will be 10 new kinds of callback; i.e., callback types with different signatures.

Yeah, that doesn't sound pleasant.

Memory Management

Yes, having to release values manually isn't very nice. Actually, weak pointers just landed in Go, so perhaps there's a way forward there: https://go-review.googlesource.com/c/go/+/628455

[stroiman]

Ah, are weak pointers in a release now? I know the feature was accepted and merged to main; which is why I chose to rely on that becoming available at some point in the future before my code had reached a level of usefulness.

Btw, as I get to know the code better, I start to have more concrete ideas about changes to code, but I think I'll just start another discussion, to keep it focused on a topic :)

And I managed to get console logs into Go code, but that's not even ready to push to my own fork yet. Depends on data in a static global var. But I started a specific branch for this feature alone, that I intend to PR.