935203 - [jsdbg2] Implement Debugger.Source.prototype.introductionType

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

From https://github.com/jimblandy/DebuggerDocs/blob/Debugger.Source/api#L1028:

"""
introductionKind

A string indicating what kind of introduction call introduced this |Debugger.Source|'s code into the system. This is |undefined| if |introductionScript| is |undefined|; otherwise, it is one of the following strings:

* "eval"
* "Function"
* "Worker"
* "importScripts"
* "handler" (for DOM elements' event handler IDL attributes)
"""

Questions:

1) What would dynamically appended <script> tags with textContent (as opposed to a src attribute) fall under? Can we differentiate those from the above kinds and from normal <script src="..."> tags?

2) "handler" is for onclick="...", etc attributes right?

Comment 1

[David Bruant]

I don't understand the undefined value semantics. All running script comes from somewhere, no?

Comment 2

[Jim Blandy :jimb]

(In reply to Nick Fitzgerald [:fitzgen] from comment #0)
> 1) What would dynamically appended <script> tags with textContent (as
> opposed to a src attribute) fall under? Can we differentiate those from the
> above kinds and from normal <script src="..."> tags?

Can't we just see if the script element has a src attribute or not?


> 2) "handler" is for onclick="...", etc attributes right?

Right. bz pointed out today that it should be named "elementAttribute", not "elementProperty", since not all DOM attributes are reflected as JS properties.

Comment 3

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I'm unassigning myself because I won't be working on this anytime soon.

Comment 4

[Sebastian Zartner [:sebo]]

Jim, Nick, any chance this will get implemented soon? This blocks our next Firebug release.

Sebastian

Comment 5

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Sebastian: no one is working on this, so I'd suggest either finding a way to unblock your release, or taking the bug yourself :(

Comment 6

[Sebastian Zartner [:sebo]]

I don't have enough Mozilla code and C++ knowledge to fix this by myself. Jim promised Honza several times to finish the last missing pieces of bug 637572. And this is an important part of it.

Sebastian

Comment 7

[Jim Blandy :jimb]

This got finished as part of bug 332176. There are two minor follow-up bugs, bug 968580 and bug 968575, waiting for review from djvj; and then bug 967769 needs someone on the Firefox side to actually *provide* the information. With that, we're done.

Comment 8

[Jim Blandy :jimb]

Attachment: Consolidate initialization of ScriptSource from CompileOptions.

Comment 9

[Jim Blandy :jimb]

Attachment: Patch 3: Provide introductionType information for all sources of JS in SpiderMonkey.

Comment 10

[Jim Blandy :jimb]

Attachment: Patch 4: Provide introductionType information for JS code appearing in event handlers.

Comment 11

[Jim Blandy :jimb]

https://tbpl.mozilla.org/?tree=Try&rev=16b539f88b3b

Comment 12

[Kannan Vijayan [:djvj]]

Comment on attachment 8379284 [details] [diff] [review]
Consolidate initialization of ScriptSource from CompileOptions.

Review of attachment 8379284 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/frontend/BytecodeCompiler.cpp
@@ +205,1 @@
>          return nullptr;

I just noticed that we don't free |ss| here.  Even the old revision didn't free |ss| before returning.  Is this a leak or is there some other mechanism that takes care of freeing this memory?

@@ +497,3 @@
>      if (!ss)
>          return false;
> +    if (!ss->initFromOptions(cx, options))

See above.

::: js/src/jsscript.cpp
@@ +1569,5 @@
> +{
> +    // Compute the length of the string in advance, so we can allocate a
> +    // buffer of the right size on the first shot.
> +    //
> +    // (JS_smprintf would be perfect, but it won't allocate from cx, and

nit: I think you mean JS_snprintf

@@ +1580,5 @@
> +                 6 /* == strlen(" line ") */    +
> +                 linenoLen                      +
> +                 3 /* == strlen(" > ") */       +
> +                 introducerLen                  +
> +                 1 /* \0 */;

style suggestion:  I wonder if moving the '+' from the end of the line, to the start of the next line (aligned with the '=' of the assign), would be more readable.

Comment 13

[Jim Blandy :jimb]

(In reply to Kannan Vijayan [:djvj] from comment #12)
> Comment on attachment 8379284 [details] [diff] [review]
> Consolidate initialization of ScriptSource from CompileOptions.
> 
> Review of attachment 8379284 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: js/src/frontend/BytecodeCompiler.cpp
> @@ +205,1 @@
> >          return nullptr;
> 
> I just noticed that we don't free |ss| here.  Even the old revision didn't
> free |ss| before returning.  Is this a leak or is there some other mechanism
> that takes care of freeing this memory?

Ah, good catch! We were always leaking ScriptSources if the ScriptSourceObject allocation failed, meaning that no GC object ever took ownership of the ScriptSource. Indeed, this patch does introduce another failure case that  would have leaked.

Comment 14

[Jim Blandy :jimb]

Attachment: Patch 1: Don't leak ScriptSources if we error out before a ScriptSourceObject can take ownership of them.

Here's a patch for the ScriptSource early-error leaks. It's not necessary for the other patches to work, unless you run out of memory and get really unlucky.

Comment 15

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

Jim, my Fx build (with the first three patches included, gecko-dev) crashes immediately after start.
Could you try to make a try build? (I need Win 32)

Honza

Comment 16

[Kannan Vijayan [:djvj]]

Comment on attachment 8379284 [details] [diff] [review]
Consolidate initialization of ScriptSource from CompileOptions.

Review of attachment 8379284 [details] [diff] [review]:
-----------------------------------------------------------------

Granting review since the memleak issue has been discussed and addressed in separate patch.

Comment 17

[Kannan Vijayan [:djvj]]

Comment on attachment 8379288 [details] [diff] [review]
Patch 3: Provide introductionType information for all sources of JS in SpiderMonkey.

Review of attachment 8379288 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.  Just one general thought.  I know we switched from having constant enums to constant cstrings for introduction types.  The explosion of different strings makes me wonder if we should have some sort of master list of what types are possible... or at least come up with a standard format/convention for the names so that client code can more easily reason about it.

For example, "no spaces in any introductionType values", "every introductionType is a dash-separated list of atoms", "if introduced by debugger, the introductionType will contain a 'debug' atom", etc.

Not saying this needs to be done.. just opening up the question for discussion and addressal sometime down the line.

Comment 18

[Jim Blandy :jimb]

(In reply to Kannan Vijayan [:djvj] from comment #12)
> > +    // Compute the length of the string in advance, so we can allocate a
> > +    // buffer of the right size on the first shot.
> > +    //
> > +    // (JS_smprintf would be perfect, but it won't allocate from cx, and
> 
> nit: I think you mean JS_snprintf

Actually, no --- JS_smprintf is a variant that dynamically allocates the result. I've expanded the comment to say that, so the name will be less surprising.

Comment 19

[Jim Blandy :jimb]

(In reply to Jim Blandy :jimb from comment #8)
> Created attachment 8379284 [details] [diff] [review]
> Consolidate initialization of ScriptSource from CompileOptions.

Unfortunately, this patch causes the JS_HoldPrincipals in the ScriptSource constructor to be never called, and neglects to call JS_HoldPrincipals at all in initFromOptions,.. with unfortunate consequences.

Comment 20

[Jim Blandy :jimb]

Attachment: Patch 2: Consolidate initialization of ScriptSource from CompileOptions. r=djvj

Fix reference-counting for principals. Carrying over r+.

Comment 21

[Emanuel Hoogeveen [:ehoogeveen]]

(In reply to Jim Blandy :jimb from comment #18)
> (In reply to Kannan Vijayan [:djvj] from comment #12)
> > > +    // Compute the length of the string in advance, so we can allocate a
> > > +    // buffer of the right size on the first shot.
> > > +    //
> > > +    // (JS_smprintf would be perfect, but it won't allocate from cx, and
> > 
> > nit: I think you mean JS_snprintf
> 
> Actually, no --- JS_smprintf is a variant that dynamically allocates the
> result. I've expanded the comment to say that, so the name will be less
> surprising.

I did something very similar to this for bug 841646. I wonder how often this comes up - if it's frequent it might be nice to add a variant of JS_s*printf that just returns the amount of characters needed to build the string. Perhaps even extend JS_snprintf to make it do that if you give it a null buffer, or something.

Comment 22

[Jim Blandy :jimb]

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #21)
> I did something very similar to this for bug 841646. I wonder how often this
> comes up - if it's frequent it might be nice to add a variant of JS_s*printf
> that just returns the amount of characters needed to build the string.
> Perhaps even extend JS_snprintf to make it do that if you give it a null
> buffer, or something.

Yes, I did think, "Well, perhaps it's time to fix JS_s*printf, then!" And I do hope it happens. But it's not something that seems like an inspiring investment at the moment.

Comment 23

[Jim Blandy :jimb]

Try push for the current patch stack:
https://tbpl.mozilla.org/?tree=Try&rev=9e81e82afbb4

Comment 24

[Jim Blandy :jimb]

Attachment: Patch 3: Provide introductionType information for all sources of JS in SpiderMonkey. r=djvj

I think this bug is cursed. Patch #3 omitted a file. Fresh try push:
https://tbpl.mozilla.org/?tree=Try&rev=6e749fddd927

Comment 25

[Jim Blandy :jimb]

Bug 964057 has introduced conflicts, so patches 1 and 2 require serious revision.

Cursed, I tell you.

Comment 26

[Jim Blandy :jimb]

Attachment: Patch 1: Don't leak ScriptSources if we error out before a ScriptSourceObject can take ownership of them. r=djvj

Rebased.

Comment 27

[Jim Blandy :jimb]

Attachment: Patch 2: Consolidate initialization of ScriptSource from CompileOptions. r=djvj

Rebased.

Comment 28

[Jim Blandy :jimb]

Attachment: Patch 3: Provide introductionType information for all sources of JS in SpiderMonkey. r=djvj

Rebased.

Comment 29

[Jim Blandy :jimb]

Attachment: Patch 4: Provide introductionType information for JS code appearing in event handlers.

Now, with Mochitests!!

Comment 30

[Jim Blandy :jimb]

Try push (fourth time's a charm!):
https://tbpl.mozilla.org/?tree=Try&rev=21fdf09b09c7

Comment 31

[Jim Blandy :jimb]

(In reply to Kannan Vijayan [:djvj] from comment #12)
> @@ +1580,5 @@
> > +                 6 /* == strlen(" line ") */    +
> > +                 linenoLen                      +
> > +                 3 /* == strlen(" > ") */       +
> > +                 introducerLen                  +
> > +                 1 /* \0 */;
> 
> style suggestion:  I wonder if moving the '+' from the end of the line, to
> the start of the next line (aligned with the '=' of the assign), would be
> more readable.

I often wish we did things this way, but SpiderMonkey style requires such operators to be at the end of the line.

Comment 32

[Jim Blandy :jimb]

(In reply to Kannan Vijayan [:djvj] from comment #17)
> Looks good.  Just one general thought.  I know we switched from having
> constant enums to constant cstrings for introduction types.  The explosion
> of different strings makes me wonder if we should have some sort of master
> list of what types are possible... or at least come up with a standard
> format/convention for the names so that client code can more easily reason
> about it.
> 
> For example, "no spaces in any introductionType values", "every
> introductionType is a dash-separated list of atoms", "if introduced by
> debugger, the introductionType will contain a 'debug' atom", etc.
> 
> Not saying this needs to be done.. just opening up the question for
> discussion and addressal sometime down the line.

This is a good point.


In general, discriminators like this can't quite do the job they seem intended for. When you add a new feature that introduces JS source, should you use an existing introduction type, or make up a new one? If it's similar to something else, using a fresh name will prevent consumers from automatically recognizing that similarity. But another consumer may want to draw finer distinctions.

So our strategy of choice in these situations should always be to provide accessors that answer the questions people *really* need answered. For example, introductionScript and introductionOffset simply show you the introducing call. The element and elementAttributeName accessors do the same for markup. For each source, we should supply whatever specific attributes our consumers need. So it's a bit like duck typing.

In that context, introductionType is really just a stop-gap, to enable a little bit more intelligence if the other parameters fall short. For example, the current batch of names is designed around Firebug's needs; and perhaps they'll be usable in labels in the UI.


In specific, I've filed bug 966720 to get the Debugger docs in-tree; once that's landed, new introduction type values should only be approved if accompanied by a doc patch.

Comment 33

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

The introductionType is now set to "handler", nice!

Yet, the script's URL should be different, derived from the parent
page URL similarly as it's done for eval and new Function scripts.

Honza

Comment 34

[Jim Blandy :jimb]

(In reply to Jan Honza Odvarko from comment #33)
> Yet, the script's URL should be different, derived from the parent
> page URL similarly as it's done for eval and new Function scripts.

So instead of "foo.html:5", you'd like to have "foo.html line 5 > handler:1"?

Comment 35

[Jim Blandy :jimb]

(In reply to Jan Honza Odvarko from comment #33)
> Yet, the script's URL should be different, derived from the parent
> page URL similarly as it's done for eval and new Function scripts.

Also, does this requirement block JSD removal? (It's fine if it does; I just want to know.)

Comment 36

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

> So instead of "foo.html:5", you'd like to have "foo.html line 5 > handler:1"?
Yes.

Note that I don't see the ":5" line number in the URL (nor for the other dynamically created scripts). In any case, it would definitely be useful in the future to have the line number (where the handler is defined in the parent HTML page) accessible somewhere (in Debugger.Script object I guess?).
In such case, the debugger can (perhaps) use the parent page source and show it to the user in the UI instead of showing the (most often) one-liner script. 


> Also, does this requirement block JSD removal? (It's fine if it does; I just want to know.)
Yes. It blocks implementing "handler" dynamic scripts since the debugger can't distinguish the URL of the handler script from the page script (when e.g. the breakpoint hits)

Honza

Comment 37

[Jim Blandy :jimb]

The original spec for Debugger.Source wanted an 'enclosingStart' property:

<dt>enclosingStart <i>(not yet implemented)</i>
<dd>The position within the enclosing document at which this source's text starts. This is a zero-based character offset. (The length of this script within the enclosing document is <code>source.length</code>.)

Set aside the fact that that's a character offset, which is a pain to turn into anything users really  care about; imagine instead that we've actually got enclosingStartLine and enclosingStartColumn accessors.

Could you use the presence of an 'element' (owning DOM element) on the Debugger.Source, plus the enclosingStartLine, to get the information you need?

I ask because:

1) I think foo.html:5 is more helpful for the other consumers of that data. Debugger is using the same data as, for example, Error().stack, and anything else that wants a source location, so it's hard to change what Debugger presents without messing up other consumers.

2) We should not be making you parse weird URLs to get the data you want.

I don't know why you're not getting :5... Looking into it.

Comment 38

[Jim Blandy :jimb]

(In reply to Jim Blandy :jimb from comment #37)
> I don't know why you're not getting :5... Looking into it.

It seems like... nobody's *ever* gotten real line numbers for event handlers???

Comment 39

[Boris Zbarsky [:bzbarsky]]

For ones that come from HTML source (or worse yet, scripted setAttribute()), that's correct.  We simply don't track that information in Gecko's HTML parser or DOM.

Comment 40

[Jim Blandy :jimb]

(In reply to Jan Honza Odvarko from comment #36)
> > Also, does this requirement block JSD removal? (It's fine if it does; I just want to know.)
> Yes. It blocks implementing "handler" dynamic scripts since the debugger
> can't distinguish the URL of the handler script from the page script (when
> e.g. the breakpoint hits)

So the issue is that the debugger doesn't know whether to display foo.html, or grab the Debugger.Source contents?

Comment 41

[Jim Blandy :jimb]

(In reply to Jim Blandy :jimb from comment #40)
> So the issue is that the debugger doesn't know whether to display foo.html,
> or grab the Debugger.Source contents?

If this is correct, then I would think that you could just use the Debugger.Source whenever the script has an owning element (Debugger.Source.prototype.element).

Comment 42

[Jim Blandy :jimb]

Providing line numbers for event handlers is difficult because 1) we put off compiling event handlers until the first time they're called, at which point we're not in the midst of parsing any more, and 2) dynamic DOM manipulation could make that line number sort of meaningless anyway. Sure, it would be nice to present the script in the context of the document structure --- but the original HTML text would be misleading. It would be better to present it as part of the inspector, if it needs to be in context at all.

Comment 43

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8380482 [details] [diff] [review]
Patch 4: Provide introductionType information for JS code appearing in event handlers.

"eventhandler" might be clearer than "handler".  r=me

Comment 44

[Jim Blandy :jimb]

(In reply to Boris Zbarsky [:bz] (reviews will be slow; ask someone else) from comment #43)
> Comment on attachment 8380482 [details] [diff] [review]
> Patch 4: Provide introductionType information for JS code appearing in event
> handlers.
> 
> "eventhandler" might be clearer than "handler".  r=me

I agree. I've changed the patch; the docs will be updated soon.

Comment 45

[Jim Blandy :jimb]

https://hg.mozilla.org/integration/mozilla-inbound/rev/75147b26aef9
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d1d368fdc10
https://hg.mozilla.org/integration/mozilla-inbound/rev/7bfc35e8d2b5
https://hg.mozilla.org/integration/mozilla-inbound/rev/684a53eafa31

Comment 46

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/75147b26aef9
https://hg.mozilla.org/mozilla-central/rev/9d1d368fdc10
https://hg.mozilla.org/mozilla-central/rev/7bfc35e8d2b5
https://hg.mozilla.org/mozilla-central/rev/684a53eafa31

Comment 47

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

(In reply to Jim Blandy :jimb from comment #40)
> (In reply to Jan Honza Odvarko from comment #36)
> > > Also, does this requirement block JSD removal? (It's fine if it does; I just want to know.)
> > Yes. It blocks implementing "handler" dynamic scripts since the debugger
> > can't distinguish the URL of the handler script from the page script (when
> > e.g. the breakpoint hits)
> 
> So the issue is that the debugger doesn't know whether to display foo.html,
> or grab the Debugger.Source contents?

I think that eventHandler scripts should have unique URL just like the other dynamically created scripts. There is no difference among them. This would allow to deal with evals, new Functions and eventHandlers the same way - e.g. when the URL appears in a stack trace.

For example: If the debugger-ui hits a breakpoint and the client gets a stack frame (with URL and line) identifying where the debugger paused, it's straightforward to find the right place - independently on what kind of script the break happened in (static, eval, new Function, eventHandler). It's always the same logic. Using the same URL for two different scripts doesn't have any advantage (at least I don't see it) and brings only an overhead for debugger-ui (to figure out what script the URL actually points to).

Note that this is currently the case. Since the eventHandler script has the same URL as the parent page, the debugger displays script of the parent page (the same for Firebug's and DevTools's debugger).

Test case:
1) Open this page: https://getfirebug.com/tests/manual/issues/7097/issue7097-4.html
2) Create a breakpoint on line 17
3) Click 'Eval' button on the page
4) In the Call stack click on 'onClick'
5) First line of the 'parent html' page is selected -> BUG


I like the way how unique URL is constructed for evals and new Functions - using the parent script URL + an identifier (line number in these cases). So, I guess the only problem here is what identifier the eventHandler script should use if the line number is not available.

---

> Sure, it would be nice to present the script in the context of the document structure ---
> but the original HTML text would be misleading.
Understand, let's forget about presenting the script in the context of the document for now.


Honza

Comment 48

[Sebastian Zartner [:sebo]]

Also scripts created via injecting <script> tags currently don't have an introductionType property.

If you need a test case, try the one from bug 865313:

https://getfirebug.com/tests/manual/mozilla/bug865313/bug865313.html

Sebastian

Comment 49

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

(In reply to Sebastian Zartner from comment #48)
> Also scripts created via injecting <script> tags currently don't have an
> introductionType property.

Just to highlight the the following case (from Sebastian's test page),
which also represents a way how to dynamically create a script:

var script = document.createElement("script");
script.textContent = "console.log('hello');";
document.body.appendChild(script);

We also need to solve the URL and line number problem, which is probably similar to eventHandlers scripts (not being in the middle of parsing + wrong lines due to dynamic DOM manipulation).
Again, debugger UI can display those scripts in separate view, so missing the line numbers (within the parent) is not a problem.

---

Different note. I have been testing Debugger.Source.element property. It's set to an Object{}, but it seems to be a plain JS object, not a DOM element (checking instanceof against Element type always returns false and listing props doesn't return anything DOMish). Any tips?


Honza

Comment 50

[Jim Blandy :jimb]

(In reply to Sebastian Zartner from comment #48)
> Also scripts created via injecting <script> tags currently don't have an
> introductionType property.

There are no fewer than *26* other spots in the browser that need introduction types set.

That's going to be a pain to test, and it'll need a zillion different reviewers. So I left that for a later patch.

Comment 51

[Sebastian Zartner [:sebo]]

> There are no fewer than *26* other spots in the browser that need introduction types set.
Which spots are that? May they be relevant for the Firebug team?

> That's going to be a pain to test, and it'll need a zillion different reviewers. So I left that
> for a later patch.
With Honza and me you already have at least two. :-)

Sebastian

Comment 52

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

(In reply to Jim Blandy :jimb from comment #38)
> (In reply to Jim Blandy :jimb from comment #37)
> > I don't know why you're not getting :5... Looking into it.
> 
> It seems like... nobody's *ever* gotten real line numbers for event
> handlers???

So, I am now getting the line number and column number for exceptions. The info is appended to URLs in the associated stack-trace. I think this is misleading since the URL can be still valid and there is no clear way to find out whether it's been appended by Firefox or part of the original URL.

Honza

Comment 54

[Jim Blandy :jimb]

Moving over Firebug's "p1" marker from the dupe, because this bug is where we should sort out what Firebug needs.

Comment 55

[Jim Blandy :jimb]

Sebastian, that blocker bug I just added should address comment 48. If you have the chance, please grab one of the builds from the Try push (assuming it succeeds!) and see if it fixes your test case.

Comment 56

[Sebastian Zartner [:sebo]]

Thanks for the info. I'll do so, though Honza will probably be faster. :-)

Sebastian

Comment 57

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

I checked the try build and the introductionType is now set to "scriptElement", nice!

Note that URL of such script is currently equal to the URL of the parent page. I don't know what the final "dynamic script's URLs" logic will be, but currently there might be more scripts with the same URL on the same page.

Honza

Comment 58

[Sebastian Zartner [:sebo]]

> Note that URL of such script is currently equal to the URL of the parent page.
Because the script is injected into the page, that sounds correct to me. The only difference may be in regard of scripts containing a //# sourceURL. In that case they may have a 'displayURL' property.[1]

Sebastian

[1] http://code.google.com/p/fbug/issues/detail?id=7201#c7

Comment 59

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

(In reply to Sebastian Zartner from comment #58)
> > Note that URL of such script is currently equal to the URL of the parent page.
> Because the script is injected into the page, that sounds correct to me.
Well, I guess Jim will like to have it set to undefined (or null).

Honza

Comment 60

[Jim Blandy :jimb]

Honza, can you try this out in the JS shell? Doesn't this kind of thing synthetize the kind of URLs you want?

var g = newGlobal();
var dbg = new Debugger;
var gDO = dbg.addDebuggee(g);


Object.defineProperty(Debugger.Script.prototype, 'derivedURL', {
  get: function () { return this.source.derivedURL; }
});

Object.defineProperty(Debugger.Source.prototype, 'derivedURL', {
  get: function () {
    switch (this.introductionType) {
    case "eval":
    case "Function":
      var fake = (this.introductionScript.derivedURL +
                  " line " + this.introductionScript.getOffsetLine(this.introductionOffset) +
                  " > " + this.introductionType);
      print("faking it: " + uneval(fake));
      return fake;
    default:
      return this.url;
    }
  }
});

g.evaluate("eval('var f = Function(\\'return 42;\\');');",
           { filename: 'glurk.js', lineNumber: 1729 });


print(gDO.getOwnPropertyDescriptor('f').value.script.derivedURL);

Comment 61

[Jim Blandy :jimb]

(I think I'm still missing the point... sorry to be so slow...)

Comment 62

[Jim Blandy :jimb]

Err, that should be 'fileName:', not 'filename:' in the call to g.evaluate...

Comment 63

[Jim Blandy :jimb]

For me this produces the output:

$ obj~/js/src/js -f ~/moz/fakeurl.js
faking it: "glurk.js line 1729 > eval"
faking it: "glurk.js line 1729 > eval line 1 > Function"
glurk.js line 1729 > eval line 1 > Function
$

Comment 64

[Sebastian Zartner [:sebo]]

> I have been testing Debugger.Source.element property. It's set to an Object{}, but it seems to be a 
> plain JS object, not a DOM element (checking instanceof against Element type always returns false and 
> listing props doesn't return anything DOMish).
For reference, I reported this in bug 979189.

Sebastian

Comment 65

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

(In reply to Jim Blandy :jimb from comment #60)
> Honza, can you try this out in the JS shell? Doesn't this kind of thing
> synthetize the kind of URLs you want?

I am facing an error: this.introductionScript is undefined

> (I think I'm still missing the point... sorry to be so slow...)
I know that we can identify every dynamic script by using other properties and fields that are now (or will soon be) available. And I guess Firebug will have to go this path at least till backend actors adopt the new API.

My point is that it would be a lot more consistent to deal with dynamic scripts the same way as with non-dynamic scripts. Do not make any difference when a breakpoint hits or an error occurs.

I like your example from comment 60 (and the way how you express things), but the real game changer would be if the debugger could be convinced to use the new URL in *all* stack traces sent back to the client (related to breakpoints, debugger; keyword, exceptions or errors, etc. etc.) 


Honza

Comment 66

[Jim Blandy :jimb]

(In reply to Jan Honza Odvarko from comment #65)
> (In reply to Jim Blandy :jimb from comment #60)
> > Honza, can you try this out in the JS shell? Doesn't this kind of thing
> > synthetize the kind of URLs you want?
> 
> I am facing an error: this.introductionScript is undefined

Are you using a current shell? introductionScript landed only last week:

changeset:   171000:6e3b9da3d83f
bookmark:    inbound
user:        Jim Blandy <[e-mail]>
date:        Wed Feb 26 15:20:00 2014 -0800
summary:     Bug 969786: Implement Debugger.Source.prototype.introductionScript. r=sfink

(In reply to Jan Honza Odvarko from comment #65)
> My point is that it would be a lot more consistent to deal with dynamic
> scripts the same way as with non-dynamic scripts. Do not make any difference
> when a breakpoint hits or an error occurs.
> 
> I like your example from comment 60 (and the way how you express things),
> but the real game changer would be if the debugger could be convinced to use
> the new URL in *all* stack traces sent back to the client (related to
> breakpoints, debugger; keyword, exceptions or errors, etc. etc.) 

Okay. If I can find time I want to propose some protocol changes that I think may address this.

Comment 67

[Jim Blandy :jimb]

(In reply to Jan Honza Odvarko from comment #49)
> Different note. I have been testing Debugger.Source.element property. It's
> set to an Object{}, but it seems to be a plain JS object, not a DOM element
> (checking instanceof against Element type always returns false and listing
> props doesn't return anything DOMish). Any tips?

It returns a Debugger.Object whose referent is the element, not the element itself.

Comment 68

[Jim Blandy :jimb]

For an example of it in use, see this test:

https://hg.mozilla.org/mozilla-central/file/e5b09585215f/toolkit/devtools/server/tests/mochitest/test_Debugger.Source.prototype.element.html#l58

Comment 69

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

(In reply to Jim Blandy :jimb from comment #67)
> It returns a Debugger.Object whose referent is the element, not the element
> itself.
I see, thanks.
Honza

Comment 70

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

(In reply to Jan Honza Odvarko from comment #57)
> I checked the try build and the introductionType is now set to
> "scriptElement", nice!
This doesn't work in Nightly nor Inbound (yet?), is that expected?

Honza

Comment 71

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

(In reply to Jim Blandy :jimb from comment #66)
> (In reply to Jan Honza Odvarko from comment #65)
> > (In reply to Jim Blandy :jimb from comment #60)
> > > Honza, can you try this out in the JS shell? Doesn't this kind of thing
> > > synthetize the kind of URLs you want?
> > 
> > I am facing an error: this.introductionScript is undefined
> 
> Are you using a current shell? introductionScript landed only last week:

I tried this also in Inbound, synced today, hg head:
date:        Thu Mar 06 11:00:26 2014 -0500
summary:     Backed out changesets e7c4304d45d7 and 75d3146ac0d3 (bug 970891) for Android reftest failures.

---

I can see that e.g. setIntroductionScript() is called in JS::OwningCompileOptions::copy (jsapi.cpp),
but when trying to access:

script.source.introductionScript (or Offset) (within Firebug code base) it's always undefined.

Any tips?

Honza

Comment 72

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

Just a bit more info related to the introductionScript field.
It works for:
Function
eval

It doesn't work for:
eventHandler
setTimeout & setInterval
scriptElement

---

Further introductionType doesn't work for:
setTimeout & setInterval
scriptElement

I don't know if/how support for Worker is supposed to work (Debugger's onNewScript hook is not even executed for Worker, since it's different thread?).

All tested on Nightly
(Built from https://hg.mozilla.org/mozilla-central/rev/8122ffa9e1aa)

In any case support for scriptElement seems to be the most useful at this point.

Honza