[jsc-dev] How to preload JS scripts into the Web Inspector Debugger without evaluating them?

Fri Jul 13 14:49:52 PDT 2018

Brian wrote:

>>> If you have have a bunch of strings that you eval some time later,
there’s no way Web Inspector would be able to infer that those are actually
scripts until they are parsed as JS and evaluated.

Yes, I understand this. I don't understand another thing:

According to your answer, even standalone parsing of the script is not
enough to display a script in the Inspector and it has to go all the way
through Interpreter:executeProgram(), right? This is odd for me. If I want
to see a script's source in the debugger, I would expect that parsing and
building AST which happens in the checkSyntax() should be enough to
understand that given chunk of text is actually a JavaScript code and we
can show it in the debugger. Why we need to also execute it for this? I'm
asking this because I still trying to find some viable solution for my
problem.

>>> It’s unclear whether this “app’s local db” is a web database or native
database, but the premise is the same: Web Inspector can’t show resources
that it hasn’t received.

It's a native database built on top of SQLite.

Kind regards,

Alexander

On Fri, Jul 13, 2018 at 11:22 PM, Brian Burg <bburg at apple.com> wrote:

> Alexander wrote:
>
>  I have a big JSON file with 400+ different JS scripts which is stored in
> the iOS app's local db. […] I want to see all of these scripts under
> Sources tab handy without actually evaluating them, […]
>
>
> If I understand what you are saying correctly, what you are trying to do
> is nonsensical. If you have have a bunch of strings that you eval some time
> later, there’s no way Web Inspector would be able to infer that those are
> actually scripts until they are parsed as JS and evaluated.
>
> Saam wrote:
>
>  I believe the reason the inspector needs to actually have the scripts
>> evaluated is once you see the scripts in the inspector, you’re able to set
>> breakpoints and such. This would not be doable without evaluating the
>> scripts.
>
>
> Under the hood, Web Inspector can set a regex breakpoint that isn’t
> resolved to a specific FunctionExecutable or whatever. However, this only
> is possible via UI interactions if the resource has been fetched and parsed
> through the normal loading mechanisms and shown in the Resources Tab. IIRC
> the most common case of unresolved/regex breakpoints is for inline scripts
> in an HTML file.
>
> It’s unclear whether this “app’s local db” is a web database or native
> database, but the premise is the same: Web Inspector can’t show resources
> that it hasn’t received. I can’t think of any other case where we would
> show a resource in Web Inspector without WebKit having tried to parse and
> evaluate it (if applicable).
>
> FWIW, engineering builds of WebInspectorUI load over 300 separate JS files
> as part of the UI, and Web Inspector can inspect itself (containing over
> 600 parsed resources) with no problem. Because the app uses MVC layering
> and namespaces, we’ve always been able to find an import order that works
> without any tool assistance. Tools like Browserify can solve this even in
> tricky cases, i.e. NPM module dependency graphs.
>
> Alexander wrote:
>
>  But I tried to call JSCheckScriptSyntax() which internally calls
> makeSource() and it didn't work. Apparently, makeSource() doesn't do an
> actual parsing? Maybe there is a way by some means to trick an Inspector's
> debugger ? Perhaps I can pre-parse those scripts somehow without evaluating
> them in a side-effectful way?
>
>
> makeSource() puts the bytes of the resource into a struct. checkSyntax()
> tries to build an AST and reports an exception if one happened. Neither
> actually evaluates the code into existence. We check syntax in many places
> (i.e., prior to running code, and for every console autocompletion) and
> wouldn’t want to show all of those in Web Inspector unless it’s something a
> developer wants to see.
>
>
>
>
>
>
>
> On Jul 13, 2018, at 1:25 PM, Alexander Karaberov <
> alexander.karaberov at gmail.com> wrote:
>
> Hi Saam and JSC folks,
>
> Is the goal here just to be able to view all the sources of your scripts?
>
>
> Yes exactly. I just want to see all of them at once, set breakpoints and
> so on.
>
> Perhaps there is a way to design these scripts so they don’t actually do
>> any work
>>
>
> Unfortunately no. Because some of those scripts are written by 3-rd party
> developers and we don't want to introduce artificial restrictions for our
> JS sandbox only to satisfy our debugging whims. This machinery should be
> completely opaque.
>
> So you said:
>
> I don’t know of a way to accomplish this without at least parsing the
>> scripts.
>>
>
>
>
> From my understanding there is no public API for this, right? One of the
> solutions might be to know an exact function which is responsible for
> loading script's source into the debugger. Then I may try to get it by
> dsym("mangled_name") and try to call. But it would be really perfect if
> there is an easier and less hack-ish way to view all the sources of the
> scripts in the debugger without evaluating them and modifying script
> sources. All the best, Alexander
>
>
> On Fri, Jul 13, 2018 at 8:41 PM, Saam barati <sbarati at apple.com> wrote:
>
>> + Some folks that work on the web inspector
>>
>> Hi Alexander,
>>
>> I don’t know of a way to accomplish this without at least parsing the
>> scripts. Is the goal here just to be able to view all the sources of your
>> scripts? I believe the reason the inspector needs to actually have the
>> scripts evaluated is once you see the scripts in the inspector, you’re able
>> to set breakpoints and such. This would not be doable without evaluating
>> the scripts.
>>
>> Perhaps there is a way to design these scripts so they don’t actually do
>> any work (like call other functions that may not yet be set up) when you
>> evaluate them. Perhaps they can just expose a single function that can be
>> called to actually make them start doing work?
>>
>> - Saam
>>
>> > On Jul 6, 2018, at 2:25 PM, Alexander Karaberov <
>> alexander.karaberov at gmail.com> wrote:
>> >
>> > Hello jsc-dev folks,
>> >
>> > I’m currently struggling with one issue. Long story short: let's say I
>> have a big JSON file with 400+ different JS scripts which is stored in the
>> iOS app's local db. When I run a dev/simulator build of the app and open
>> Safari --> Develop --> Debugger I want to see all of these scripts under
>> Sources tab handy without actually evaluating them, otherwise debugging
>> process becomes a bit cumbersome. Also our app is used by a lot of
>> JavaScript developers who develop custom scripts for it, normally they use
>> a simulator + Safari Debugger and they also want to see all the scripts at
>> once. From my understanding for the JS script to be visible in the Debugger
>> --> Sources tab it has be evaluated first. And indeed if I call
>> JSEvaluateScript() in a for-loop for all the 400+ scripts stored in the
>> file it works and I can see all of them in the Debugger. The problem with
>> this approach is that it causes an avalanche of different side-effects,
>> exceptions thrown and so forth, because some scripts call another ones,
>> some scripts are not ready yet to be called (some of the libs or modules
>> were not loaded for instance), some are not intended for execution at the
>> given moment at all and etc. So I have to come up with a different solution
>> and make Inspector's Debugger aware of all the JS scripts at once without
>> executing all of them. In the best case scenario I want something akin to
>> (roughly) JSInspectorLoad(script) which I will call for all the scripts in
>> the file. I tried to call JSCheckScriptSyntax() in a loop in the same way,
>> but it didn’t work. It finds and reports errors but nonetheless in the
>> Debugger I see only those scripts which have already been evaluated. I
>> checked JavaScriptCore code and it seems that all the interesting logic
>> related to Debugger/Inspector resides somewhere inside of
>> profiledEvaluate() function namely either in the CodeProfiling
>> profile(source) or vm.interpreter->executeProgram(). All those calls are
>> private and unfortunately unavailable via the scarce JavaScriptCore public
>> API. My next silly idea is to somehow get pointers to proper functions via
>> the dlsym() and then call them, but I don’t even know where to start with
>> this. Modifying and rebuilding my own version of JavaScriptCore together
>> with its dependencies (bmalloc, WTF) and shipping all these (potentially
>> broken) things with the app is definitely not an option for me.
>> > I will highly appreciate if someone suggests a different approach to
>> preload scripts to the Debugger without evaluating them. Maybe I'm missing
>> something and there is actually a way to do this, because I really need
>> this feature. Thank you very much in advance!
>> >
>> > Kind Regards,
>> > Alexander
>> >
>> > _______________________________________________
>> > jsc-dev mailing list
>> > jsc-dev at lists.webkit.org
>> > https://lists.webkit.org/mailman/listinfo/jsc-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/jsc-dev/attachments/20180713/3b002f02/attachment.html>