750317 - Debugger.Script.url isn't a simple path

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Gregory Szorc [:gps]]

When accessing Debugger.Script.url, I'm getting strings that look like mappings. e.g.

"/Users/gps/src/services-central/testing/xpcshell/main.js -> file:///Users/gps/src/services-central/testing/xpcshell/head.js"

I'm not sure if this is intentional or what. I would prefer that if there are multiple representations of the script path/url, that they would be exposed as different properties. i.e. I shouldn't need to parse strings.

My STR are essentially:

1) Create sandbox, s1, to execute code in.
2) Load a file via mozIJSSubScriptLoader.loadSubScript inside the sandbox
3) Create sandbox, s2, for the debugger
4) Load debugger in sandbox s2. Hook up debugger to execution sandbox, s1.
5) Register onEnterFrame, onStep which capture this.script.url inside onStep
6) Call eval on loaded code in execution sandbox, s1

In the example above, main.js is the file containing the code to instantiate and run the two sandboxes. head.js was a file loaded via loadSubScript() inside the execution sandbox, s1.

Comment 1

[Boris Zbarsky [:bzbarsky]]

From the JS engine's point of view, the .url is just an opaque string.

In this case, the consumer (some XPConnect code) is creating a script with the "url" set to the above string, because it needs certain behavior out of yet other code that does security checks via prefix match on the script url.

Comment 2

[Gregory Szorc [:gps]]

(In reply to Boris Zbarsky (:bz) from comment #1)
> From the JS engine's point of view, the .url is just an opaque string.
> 
> In this case, the consumer (some XPConnect code) is creating a script with
> the "url" set to the above string, because it needs certain behavior out of
> yet other code that does security checks via prefix match on the script url.

Interesting. But, I think this is unacceptable from an API consumer perspective. If I want to cross-reference the original source file, I shouldn't have to work through some XPConnect implementation detail.

Comment 3

[Boris Zbarsky [:bzbarsky]]

You have to anyway to some extent, if by "API consumer" you mean a consumer of the debugging API: XPConnect (or any JSAPI consumer) can always lie about the actual source location when it calls JS_CompileScript.  Which is what it's doing right now anyway.  So for example, it could have just passed the "/Users/gps/src/services-central/testing/xpcshell/main.js" part, since that's the part it really cares about itself.

That said, having some sort of API support for whatever XPConnect is doing here so the hack in XPConnect could be removed would be nice...  jst, Blake, do you recall why we needed that?