983297 - SpiderMonkey should guess which JS code caused new JS code to be compiled

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Jim Blandy :jimb]

JavaScript code can do all sorts of things that cause other JavaScript code to be compiled: calling 'eval' or 'Function'; inserting <script> elements; passing strings of code to setTimeout; and so on. It would be nice to know, for any given bit of JS code, which operation caused it to be introduced into the system.

Within SpiderMonkey, ScriptSourceObjects and ScriptSources can record this "introduction info", if it is provided in the JS::CompileOptions structure passed to the compiler. But most places in Firefox that invoke the JS compiler don't pass such information.

It would be possible to simply grab the top JS frame, and presume that whatever that is must be the thing that requested the compilation. But this could be wildly wrong in some cases --- if JS spins up a nested event loop, for example, and then that event loop invokes a C++ handler that compiles some JS, then the top JS frame has absolutely no relation to the JS compilation at all; it would be misleading to record it.

At the same time, being able to point to the 'document.appendChild(scriptElt)' call that caused the script element's code to run would be pretty awesome.

So I'm not quite sure how to approach this. Perhaps in almost every case the top JS frame is perfectly meaningful, and the win is worth a few false positives.

Comment 1

[Jim Blandy :jimb]

Great news:

<bz> jimb: When we spin a nested event loop there is no top JS frame, fwiw
<bz> jimb: We set the stack aside
<bz> jimb: precisely because examining it is kinda nonsense
<bz> jimb: When the top JS frame exists, it's actually reliable
<bz> jimb: So we could in fact capture information from it at that point

Comment 2

[Jim Blandy :jimb]

The approach to take here, I think, would be to start with js::DescribeScriptedCallerForCompilation from js/src/jsscript.cpp and turn it into a method of JS::CompileOptions, to simply load up 'this' CompileOptions with the appropriate values for the current scripted caller. In most use cases, DescribeScriptedCallerForMyMom'sCompilationBecauseLastYearWeDidn'tReallyKnowWhatWasUpSoItCameAs
ATotalSurpriseYouKnowAndSoYeahWeWantToAvoidThatIfIt'sPossible is just used to populate a CompileOptions anyway, so this should be a nice cleanup.

Then, we can add calls to that new JS::CompileOptions method to the spots in Firefox that call the compiler.

Comment 3

[Jim Blandy :jimb]

Of course, one may also say:

var s = document.createElement('script')
s.setAttribute('src', 'http://www.red-bean.com/jimb/alert.js');
document.body.appendChild(s)

in which case the compilation happens when the HTTP request completes, at which point the stack frame that called appendChild is long gone. So what's also/instead needed is a way to capture introduction information to be used in a later compilation.

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Do we have ETA for this issue?

Honza

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.