Re: [heycam/webidl] Modernize invoking user code (#113)

Or more precisely, it has whatever the window1 script was that called the Function ctor as script-or-module.  But the point is that the [[Realm]] of the [[ScriptOrModule]] of the function involved doesn't match the [[Realm]] of the function itself (and this is the only way to produce this situation!), so it really starts to matter how we go about getting to the Realm.

For what it's worth, at least in Firefox in this case the function looks in all ways like it came from window2, except that the "filename" string is something like "urlofWindow1 line N > Function".  Note that this is NOT the same thing as "urlofWindow1", which is what I think you're saying the current setup in the spec does, and is a lot more useful...

Actually, I just went ahead and put up a testcase so we can see what UAs do here: <http://web.mit.edu/bzbarsky/www/testcases/javascript/newFunction-parent.html>.  The output for the top stack frame is the following in various browsers:

* Firefox: `anonymous@http://web.mit.edu/bzbarsky/www/testcases/javascript/newFunction-parent.html line 5 > Function:1:7`
* Chrome: `at eval (eval at onload (http://web.mit.edu/bzbarsky/www/testcases/javascript/newFunction-parent.html:5:13), <anonymous>:2:7)`
* Safari: `anonymous`
* Edge: `at Function code (Function code:1:1)

none of those have `"http://web.mit.edu/bzbarsky/www/testcases/javascript/newFunction-parent.html"` as the filename, and Chrome and Firefox have something much more useful instead.  I don't think we really want to be using the script-or-module of the caller of `new Function` to set the filename if it would require all of them to claim that this error occured in `"http://web.mit.edu/bzbarsky/www/testcases/javascript/newFunction-parent.html"`.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/113#issuecomment-218630061