977255 - [jsdbg2] Dynamic scripts should not have false URLs

Status: RESOLVED DUPLICATE of bug 957798

(Core :: JavaScript Engine, defect)

Description

[Jim Blandy :jimb]

For eval and 'new Function' script sources, Debugger.Source.prototype.url returns the URL of the closest document in the "introduction chain" that had a URL, which is not a URL at which that source can be found.

That is:

    $ cat weirdurl.js
    var g = newGlobal();
    var dbg = new Debugger;
    var gDO = dbg.addDebuggee(g);

    dbg.onDebuggerStatement = function (frame) {
      print("url: " + frame.script.url);
    };
    g.eval('eval("Function(\\"debugger;\\")()");');
    $ dbg/js/src/obj~/js/src/js -f weirdurl.js
    url: weirdurl.js
    $ 

Here, the introduction chain is that g.eval calls eval which calls the Function constructor. Only the outermost call appears in a script with a URL, so that's the URL that the innermost script inherits.

This is bogus. Fetching 'weird.js' does not give you the source that script is running --- 'debugger;'.

Debugger.Source.prototype.url should return 'undefined' on such scripts. The other D.S accessors like introductionType, introductionScript, introductionOffset, element, and elementAttributeName, should provide more than enough information for consumers to synthesize descriptions that are appropriate to their use cases.

Comment 1

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

One thing we need to ensure is that the front end is able to identify the right location when getting a stack-frame from the debugger.

The stack frame is there to identify a location via:

- URL
- line
- column (later)

SO, if the debugger pauses and sends a stack-trace to the client, the client needs to know which Script the execution is in and at what line(+column)

Currently the special URL is *very easily* used to uniquely identify the script and it's easy for the client to find it (or request associated source from the back-end). 


So, how the stack frame will look like if the debugger breaks in a dynamically created script?
How the frontend will find out the location?

This might be off, but:
How the JSON packet will look like? It wouldn't be effective if the front end needs to spin additional request to get extra data for the stack-frame (or entire stack-trace).

When I go back to the argument:
"There is no URL you could fetch to retrieve that script..."

Why the dynamic URL can't be actually used to fetch the dynamic script?

Honza

Comment 2

[Jim Blandy :jimb]

At the protocol level, the pieces aren't in place for this to work correctly at the moment. That's something that's on my plate to address.

Eventually, we'll be passing <source actor, line, column> around where we now pass <url, line, column> around. Source actors will have a URL when it makes sense, and other introduction information when a URL doesn't make sense. Then, we can unambiguously refer to specific dynamically-generated texts via their source actor names.

If a client needs to use URL strings to refer to sources, then it can maintain a map from these URL strings to source actor names. But if you have multiple sources arising from different calls to a given eval call site, it's hard to imagine how one is going to generate distinct URLs without adding disambiguating text, like a serial number or some such. Then, that looks an awful lot like a source actor name.

Comment 3

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/47f2dfde8e4d

Comment 4

[Jim Blandy :jimb]

Carsten, the bug number in that changeset was a typo. This bug is still open.

Comment 5

[Carsten Book [:Tomcat]]

hi Jim, yeah sorry was error in the commit message and should be 977257, i pinged nical and the correct bug is resolved, sorry again :)

Comment 6

[Jim Blandy :jimb]

Thanks very much!

I sounded cranky in comment 4; I apologize for that. You guys are handling a lot of stuff, and I understand this kind of thing will happen from time to time.

Comment 7

[Florian Bender]

Aren't this and Bug 957798 dupes?

Comment 8

[Jim Blandy :jimb]

(In reply to Florian Bender from comment #7)
> Aren't this and Bug 957798 dupes?

Yes - thanks.