Current interop issue: URL/line/column number computation

[domenic]

According to https://bugs.chromium.org/p/chromium/issues/detail?id=729137#c5 , different browsers fail at this in different ways:

Safari and Edge don't support //# sourceUrl for renaming scripts in inline JS and eval'ed JS. Chrome doesn't compute correct line numbers for inlined JS.

[ljharb]

Since line numbers are optional (by design), I think Chrome's behavior there won't be problematic.

Similarly, if sourceUrl isn't supported, I think that would just be handled by a polyfill in a transparent way.

[yungcheng]

Just a note, when using sourceURL, Chrome formats new Function differently from eval with sourceURL. Here's an example:

new Function('', `console.log('foo from function')
                 //# sourceURL=foo-function.js`);
const script = `function foo() {
               console.log('foo from eval');
             }
             //# sourceURL=foo-eval.js`;
eval(script);

it would result in two files in dev tool Sources tab foo-eval.js and foo-function.js
foo-eval.js

function foo() {
               console.log('foo from eval');
             }

foo-function.js

(function(
/*``*/) {
console.log('foo from function')
})

The behavior creates an issue when I tried to locate actual error block by line and column number, so I end up removing the usages of new Function from our code.

[mknichel]

The line and column information in stack traces is important to ensure that renamed and minified code on the client can be deobfuscated on the server to produce a stack trace that points to the original source files and symbols. We (Google) rely on this to correctly handle JS errors from our properties. Since there are many differences and issues across browsers today, we're hoping to standardize this in the spec to make deobfuscation possible and consistent across all browsers.

[plauclair]

Just a FYI, JavaScriptCore on iOS also has differences. The stack has no line or column information, but the Error has line and columns properties, those coordinates refer to the location of the first stack frame. There is no file name available either.

[ljharb]

The filename could be an empty string.

As for the stack info; since the engine has the information, it seems like a polyfill would be possible.