Currently we do not have API to make a JSCContext remotely inspectable, and to start the remote inspector server. This can be handy for programs which use the JSC API directly to embed a JSCContext and run scripts without relying on a WebKitWebView.
Created attachment 399606 [details] RFC Patch
(In reply to Adrian Perez from comment #1) > Created attachment 399606 [details] > RFC Patch Usage example for the added API functions: https://git.sr.ht/~aperezdc/kiln/commit/dd52f9e7569061714bc6f21cb282e8e3130b8100
Somehow using jsc_inspector_server_start("127.0.0.1", 12345) followed by jsc_context_set_inspection_enabled(ctx, TRUE) does not seem to be enough to make the JS context appear as an inspectable target when opening inspector://127.0.0.1:12345 in MiniBrowser… I'll have to take another look. Any suggestion on where to look would be welcome :)
Comment on attachment 399606 [details] RFC Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399606&action=review Clearing r? because this is a WIP. Please set r? when it's not a WIP and feel free to nag for feedback even if you don't set r?. > Source/JavaScriptCore/API/glib/JSCContext.cpp:1126 > + auto* globalObject = toJSGlobalObject(context->priv->jsContext.get()); This is one of those cases where auto doesn't help us. It's not a super big deal, but I thought I'd share my thinking here. Lots of JSC code, include things like this, is going to be read more times by more people than it is written or modified, so you putting in the effort to write "JSGlobalObject*" instead of "auto*" is a net win for the project. I don't think that this is always true. But I do think it's true for dealing with sketchy JSC god objects like JSGlobalObject.