Closed Bug 807845 Opened 7 years ago Closed 7 years ago

provide a jsfriendapi to ask "who is my caller's outermost enclosing function"?

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla19
Tracking Status
firefox18 --- fixed

People

(Reporter: luke, Assigned: luke)

References

Details

Attachments

(1 file)

What sort of sick person would want to do such a thing?  See bug 798491.  XPConnect has some import() call and wants to figure out "which module called import()"?  Previously, we could just ask for the global of the import() function.  Now, all the modules live in the same global so we need a finer-granularity question.

Note: this uses the newly-added StaticScopeIter which will "stop" it's outward iteration at eval() boundaries.  khuey says 'that's ok'.
Attached patch patchSplinter Review
Attachment #677627 - Flags: review?(jimb)
Attachment #677627 - Flags: feedback?(khuey)
Comment on attachment 677627 [details] [diff] [review]
patch

Review of attachment 677627 [details] [diff] [review]:
-----------------------------------------------------------------

This appears to do the trick.
Attachment #677627 - Flags: feedback?(khuey) → feedback+
Will this still work for calls to 'import' in scripts brought in via loadSubScript? For example, toolkit/devtools/debugger/server/dbg-server.jsm uses mosIJSSubScriptLoader::loadSubScript to load toolkit/devtools/debugger/server/dbg-server.js, which calls Cu.import. I would expect the caller of that Cu.import to be the frame created by loadSubScript, which I don't think is a function body.

mozJSSubScriptLoader::LoadSubScript uses JS_ExecuteScriptVersion at js/xpconnect/loader/mozJSSubScriptLoader.cpp:297 to run the script, after fetching it from a cache or compiling the source if the cache doesn't have it. JS_ExecuteScriptVersion calls js::Execute which calls ExecuteKernel which pushes an EXECUTE_GLOBAL frame, which I think will cause GetOutermostEnclosingFunctionOfScriptedCallerABCDEFGHIveGotAGalInKalamazoo to return NULL.
Comment on attachment 677627 [details] [diff] [review]
patch

Review of attachment 677627 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me.
Attachment #677627 - Flags: review?(jimb) → review+
needinfo re: comment 3.

Also, khuey, should I just land this?  Is this part of some patch queue that I assume needs to go on aurora?
Flags: needinfo?(khuey)
I don't have confirmation from the B2G folks that the patch I wrote on top of this fixes the issues we were seeing yet.  Lets wait for that before landing.
Flags: needinfo?(khuey)
Righto.  Here's inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/843a3db9c045

Perhaps you'd like to make the aurora request?
https://hg.mozilla.org/mozilla-central/rev/843a3db9c045
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Comment on attachment 677627 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 807478
User impact if declined: can't run RIL xpcshell tests (neither locally nor on infra, the latter of which should happen soon)
Testing completed (on m-c, etc.): not yet
Risk to taking this patch (and alternatives if risky): virtually none, just adds another function to the jsfriend API.
String or UUID changes made by this patch: none
Attachment #677627 - Flags: approval-mozilla-aurora?
Comment on attachment 677627 [details] [diff] [review]
patch

In support of B2G testing, and very low risk. Approving.
Attachment #677627 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.