1178687 - Show locations for unnamed eval sources consistently across tools

Status: NEW

(DevTools :: Debugger, enhancement, P5)

Description

[Till Schneidereit [:till]]

Attachment: Test case

Eval'd code usually shows up in the debugger since bug 905700 has landed. In the attached test case it only shows up if the debugger is enabled and set to pause on exceptions, though. Even then, it doesn't show up with the correct name/description, but with the name "SCRIPT0". In the console, the location is "<unknown>".

STR:
1. Open attachment.
2. Open console, observe that the exception's location is "<unknown>".
3. Open debugger, observe that the eval'd code is absent from the list of sources.
4. Reload with "Pause on exceptions" active, observe that the eval'd code now shows up, but with "SCRIPT0" as the name.

Comment 1

[James Long (:jlongster)]

We don't show unnamed eval sources in the debugger by default. There are far too many on most sites and they don't have any way to describe them, so the debugger would just be full of "unknowns" or "scriptN" names.

In order to allow debugging these sources though, they do appear if the debugger pauses in one of them.

What do you mean it doesn't show up with the correct name/description? There is no correct name/description, they are not named anything. You need to append an eval script with `// sourceURL=foo.js` to give it a name if you want it to appear by default.

Note that we did show all eval sources when we first landed eval support, and got many complaints about cluttering up the debugger (for good reason).

Comment 2

[Till Schneidereit [:till]]

(In reply to James Long (:jlongster) from comment #1)
> We don't show unnamed eval sources in the debugger by default. There are far
> too many on most sites and they don't have any way to describe them, so the
> debugger would just be full of "unknowns" or "scriptN" names.

I see, that makes sense. It'd be nice to have at least the option to show them all, perhaps with a "show anonymous scripts" button or so. However, seeing as how I didn't realize that we didn't show them until I investigated bug 1177941, perhaps it's not all that important ...


> In order to allow debugging these sources though, they do appear if the
> debugger pauses in one of them.

Ok.


> What do you mean it doesn't show up with the correct name/description? There
> is no correct name/description, they are not named anything. You need to
> append an eval script with `// sourceURL=foo.js` to give it a name if you
> want it to appear by default.

I meant something like "[outer scope] > <unknown>" or "[outer scope] > <anonymous>" or similar. (Where "[outer scope]" is e.g. the function containing the eval/new Function call.)

More importantly, the "<unknown>" in the console seems weird. I just tested with a "//# sourceURL=foo" appended to the end of the function body: same result. This seems to be caused by throwing a primitive value instead of an Error instance. If I do that, I get correct source coordinates, but the URL is (in my specific case) "[..]/test.html line 7 > Function". This is regardless of whether I provide a sourceURL or not.

> Note that we did show all eval sources when we first landed eval support,
> and got many complaints about cluttering up the debugger (for good reason).

Yeah, I see how that'd be annoying. The correct linking of locations in the console seems to be the important bit here.

Comment 3

[James Long (:jlongster)]

Yeah, the way we handle locations right now is wildly inconsistent. This is actually related to sourcemaps too: when a source is sourcemapped we really want to show all the locations as the correct sourcemapped file/line.

We are actively working on sourcemaps in Q3, and probably going to land them in the console. That effort will include consolidating all of our location representations to make them consistent, and we can work on making things like eval sources consistent too.

Comment 4

[James Long (:jlongster)]

This is still a valid bug, but I'm renaming it to make sure we revisit unnamed eval sources when we have better location functionality.