Closed Bug 935203 Opened 11 years ago Closed 10 years ago

[jsdbg2] Implement Debugger.Source.prototype.introductionType

Categories

(Core :: JavaScript Engine, defect)

25 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: fitzgen, Assigned: jimb)

References

(Depends on 1 open bug)

Details

(Whiteboard: [firebug-p1])

Attachments

(5 files, 5 obsolete files)

15.33 KB, patch
Details | Diff | Splinter Review
2.84 KB, patch
Details | Diff | Splinter Review
11.87 KB, patch
Details | Diff | Splinter Review
15.37 KB, patch
Details | Diff | Splinter Review
7.48 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
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?
Flags: needinfo?(jimb)
I don't understand the undefined value semantics. All running script comes from somewhere, no?
(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.
Flags: needinfo?(jimb)
I'm unassigning myself because I won't be working on this anytime soon.
Assignee: nfitzgerald → nobody
Jim, Nick, any chance this will get implemented soon? This blocks our next Firebug release.

Sebastian
Sebastian: no one is working on this, so I'd suggest either finding a way to unblock your release, or taking the bug yourself :(
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
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.
Depends on: 968580, 968575, 967769
Summary: [jsdbg2] Implement Debugger.Source.prototype.introductionKind → [jsdbg2] Implement Debugger.Source.prototype.introductionType
Assignee: nobody → jimb
Status: NEW → ASSIGNED
Attachment #8379284 - Flags: review?(kvijayan)
Attachment #8379290 - Flags: review?(bzbarsky)
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.
(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.
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.
Attachment #8379375 - Flags: review?(kvijayan)
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
Attachment #8379375 - Flags: review?(kvijayan) → review+
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.
Attachment #8379284 - Flags: review?(kvijayan) → review+
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.
Attachment #8379288 - Flags: review?(kvijayan) → review+
(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.
(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.
Fix reference-counting for principals. Carrying over r+.
Attachment #8379284 - Attachment is obsolete: true
Attachment #8379288 - Attachment description: Provide introductionType information for all sources of JS in SpiderMonkey. → Patch 3: Provide introductionType information for all sources of JS in SpiderMonkey.
Attachment #8379290 - Attachment description: Provide introductionType information for JS code appearing in event handlers. → Patch 4: Provide introductionType information for JS code appearing in event handlers.
Attachment #8379375 - Attachment description: Don't leak ScriptSources if we error out before a ScriptSourceObject can take ownership of them. → Patch 1: Don't leak ScriptSources if we error out before a ScriptSourceObject can take ownership of them.
(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.
(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.
Try push for the current patch stack:
https://tbpl.mozilla.org/?tree=Try&rev=9e81e82afbb4
Attachment #8379288 - Attachment is obsolete: true
OS: Mac OS X → All
Hardware: x86 → All
Attachment #8380302 - Attachment description: Provide introductionType information for all sources of JS in SpiderMonkey. r=djvj → Patch 3: Provide introductionType information for all sources of JS in SpiderMonkey. r=djvj
Bug 964057 has introduced conflicts, so patches 1 and 2 require serious revision.

Cursed, I tell you.
Now, with Mochitests!!
Attachment #8379290 - Attachment is obsolete: true
Attachment #8379290 - Flags: review?(bzbarsky)
Attachment #8380482 - Flags: review?(bzbarsky)
Try push (fourth time's a charm!):
https://tbpl.mozilla.org/?tree=Try&rev=21fdf09b09c7
(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.
(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.
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
(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"?
(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.)
> 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
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.
(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???
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.
(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?
(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).
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.
Attachment #8380482 - Flags: review?(bzbarsky) → review?(bugs)
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
Attachment #8380482 - Flags: review?(bugs) → review+
(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.
(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
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
(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
(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.
> 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
(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
Moving over Firebug's "p1" marker from the dupe, because this bug is where we should sort out what Firebug needs.
Whiteboard: [firebug-p1]
Depends on: 978657
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.
Thanks for the info. I'll do so, though Honza will probably be faster. :-)

Sebastian
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
> 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
(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
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);
(I think I'm still missing the point... sorry to be so slow...)
Err, that should be 'fileName:', not 'filename:' in the call to g.evaluate...
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
$
> 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
(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
(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 <jimb@mozilla.com>
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.
(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.
(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
(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
(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
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: