Bug 212002

Summary: [GLIB] Add API to make JSCContext remotely inspectable
Product: WebKit Reporter: Adrian Perez <aperez>
Component: JavaScriptCoreAssignee: Adrian Perez <aperez>
Status: ASSIGNED ---    
Severity: Normal CC: annulen, cgarcia, ews-watchlist, fpizlo, gyuyoung.kim, keith_miller, mark.lam, msaboff, ryuan.choi, saam, sergio, tzagallo
Priority: P2    
Version: WebKit Local Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=212987
https://bugs.webkit.org/show_bug.cgi?id=216120
Bug Depends on: 237646    
Bug Blocks:    
Attachments:
Description Flags
RFC Patch none

Description Adrian Perez 2020-05-17 14:10:38 PDT 
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.
Comment 1 Adrian Perez 2020-05-17 14:11:44 PDT 
Created attachment 399606 [details]
RFC Patch
Comment 2 Adrian Perez 2020-05-17 14:17:47 PDT 
(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
Comment 3 Adrian Perez 2020-05-17 14:28:02 PDT 
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 4 Filip Pizlo 2020-06-13 13:30:13 PDT 
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.