Closed Bug 699179 Opened 13 years ago Closed 8 years ago

JSD should allow creation of jsdscripts even when the line number is 0

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: noel.sharrock, Unassigned)

Details

(Whiteboard: [firebug-p1])

Attachments

(3 files)

Attached file console_bug.zip
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

I used the Dojo Toolkit to develop a tab based tool for project management. 
The site dynamically loaded the content for each tab on demand and executed any script found.
I found issues with error reporting.

I reported the issue to Fiebug but they refereed it back to Firefox.
http://code.google.com/p/fbug/issues/detail?id=4145



Actual results:

When JavaScript Errors were reported they showed the correct line number and type of error.
However the line of script displayed in Firebug was from the parent file also the file name was the parent file name.

A test case is attached.


Expected results:

I would have expected that the correct source was identified or if that was not possible then not displaying incorrect source information. 

There other problems with dynamically loaded script that are out of scope here.
Attachment #571407 - Attachment mime type: application/octet-stream → application/zip
What Dojo does in this case is to grab the text contents of contentPane.html and then parse it or something, extract the contents of the <script> and then createElement("script") in the main page, stick that text inside it, and put it in the DOM.

So from our point of view, the script is in fact running in issue4145.html and we have no way to tell where the text came from.

In any case, the filename is correct: it's an inline script in issue4145.html.

The line number is somewhat bogus: it's the offset of the line in that <script> tag, because we don't have a line number for the script tag.  We could just display no line number at all, but it seems like displaying _something_ that can help debug is better than just being completely silent.

The ideal thing here would be if dojo added source notes indicating where it got the script text, of course.
Boris, please see http://aspspider.net/jagalves/TestPageHtml.htm, which simplifies the problem.

See the related Firebug issue:
http://code.google.com/p/fbug/issues/detail?id=3708

Firebug can't access the contents of dynamically added <script> tags, because it just displays the static source.
I am not that much into JSD, but is there a possibility to debug the "alert('firebug won\'t see this either');" line of that script?
Well, JSD certainly knows about it.  I have no idea what he problem is on the Firebug end.
Hi Boris,

So what meta data does JSD know about the error?
The source code, the actual error, the position in the source code? ....

Is there enough information available to provide the console/Firebug with the context of the error?
If not what would have to happen in order to provide accurate debugging information?

Noel
> So what meta data does JSD know about the error?

Exactly what you see in the console: the line number in the <script>, the URL of the <script>, and the actual error.

It also knows the full text of the <script> involved, of course.  Between that and the line number in the <script> it should be debuggable, yes?
In the test case of comment 2 there is no error. Firebug sees the compilation unit for the event handler, but not for the actual code of doit().

Steps to reproduce (from a user's view):
1. Open Firebug on http://aspspider.net/jagalves/TestPageHtml.htm
2. Enable and switch to the Script panel
3. Reload the page
4. Click the "Click me" button on the page
5. Click the script location button inside Firebug (saying "TestPageHtml.htm")

=> There's one "onclick" event handler listed in the menu, but the injected <script> code is missing

Honza, you might be able to say more about that.
Boris,
Comment 5 was referring to injected code as in both examples (console_bug.zip attached and Sebastian's example in comment 2)
Attached file Test extension
I think that the problem is related to Bug 566446 - javascript added to document through appendChild are not handled by jsd.

I am not seeing that onScriptCreated (jsd.scriptHook) would be executed for the <script> element appended into the document. So, Firebug doesn't know about the script.

I don't know if it's the only problem, but it's a blocker on Firebug side.

Attach a simple extension that shows the problem.

STR:

1) install the extension (tested with Aurora, since Nightly is crashing due to bug 700311)
2) Load http://aspspider.net/jagalves/TestPageHtml.htm
4) click the button on the page (appending a <script> element to the page)
3) watch the system console or Firefox Error Console (or FBTrace console if installed).

You should see:
onScriptCreated http://aspspider.net/jagalves/TestPageHtml.htm, onclick, 1

This is a script created for:
<button onclick="doit()">Click me</button>
event handler

There is no onScriptCreated called for the appended script.

Honza
Boris, could you take a look at my STR in comment 8?

It's related to bug 566446, see:
https://bugzilla.mozilla.org/show_bug.cgi?id=566446#c1

JJB is saying: "scripts created by appending script elements do not use the normal paths" 

You are saying: Actually... they do. At least on the Gecko side they follow the same exact codepaths as any other script.

But I the onScriptCreated is not executed for me...

Honza
Looks like _newJSDScript bails out if the script's lineno is 0, as it is in this case.
(In reply to Boris Zbarsky (:bz) from comment #10)
> Looks like _newJSDScript bails out if the script's lineno is 0, as it is in
> this case.
Sounds promising!

I am marking as [firebug-p1] since this has been reported many times in Firebug issue list. This would be great to have fixed!

Honza
Whiteboard: [firebug-p1]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: The integrated Error Console shows a correct line number and incorrect (parent) file name in reporting a JavaScript error when a script is loaded dynamically with Dojo Toolkit → JSD should allow creation of jsdscripts even when the line number is 0
The CVS blame looks like this:

102 ltabb 1.1 /* these are inlined javascript: urls and we can't handle them now */
103 jband 3.2 lineno = (uintN) JS_GetScriptBaseLineNumber(cx, script);
104 ltabb 1.1 if( lineno == 0 )
105             return NULL;

so the code has been this way ever since revision 1.1.  Revision 1.1 in this case is the original open-sourcing of the Mozilla source code by Netscape.

sfink, thoughts on just removing that check?
After skimming the related bugs, it seems like zero was intended to be a way to mark scripts that *should not* be handed to JSD, and that it was a bug to pass in zero for any other reason. Today, it seems like JSD can handle any script you give it, and various ways of getting lineno==0 have crept in.

So yes, I'm all for removing the check. Better to get scripts with wrong line numbers than to not get them at all. I'll run it by timeless, though, since he would be likely to know if there are any gotchas.
Having this fixed would make my day.
I live in AJAX land. A foggy land with out a fire to illuminate bugs.
Over IRC, timeless said he thinks this is the wrong solution. He went on to say:

12:02 <   timeless> if you generate a url each time you do a createElement script
12:02 <   timeless> that you can use line 1 as the line number w/o lying
12:03 <   timeless> the url will not be the page url, but it could encode the page url
12:03 <   timeless> it could be something like:
12:03 <   timeless> data:text/json,{baseurl:"...",callingurl:"...",callerline:x}
12:04 <   timeless> where baseurl is window.document.location (or something like it), and callingurl+callerline are from the caller js frame
12:05 <   timeless> you could even have fun and each time someone calls appendChild() on your Script Node, have it adjust the url to record the additional caller frame
12:06 <   timeless> that's roughly the path to sanity
12:07 <   timeless> http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#119
12:08 <   timeless> is roughly where you'd look to go about hooking
12:08 <   timeless> you might even be able to abuse the non xpcom codepaths we're using
12:13 <   timeless> you could only trap cases where you're coming from js
12:13 <   timeless> and you could fairly easily grab the file+line info you need
12:13 <   timeless> there of course is /some/ concern about overhead for this info
12:14 <   timeless> right now because these things are line 0, they're much faster
12:14 <   timeless> iirc people worried that my fixing the event handler thing would hurt perf :)

bug 637572 looks like it's the current longer-term thinking about this.

Would allowing these through JSD with the wrong line number (0) but the "right" filename actually help? You would know that the script had been called, but you wouldn't be able to set breakpoints or anything. (Or does Firebug use the decompilation-based stuff? Does that stuff still work in JSD?)
(In reply to Steve Fink [:sfink] from comment #16)
> Would allowing these through JSD with the wrong line number (0) but the
> "right" filename actually help? You would know that the script had been
> called, but you wouldn't be able to set breakpoints or anything.
I don't understand why breakpoints couldn't be set. Is that because the line numbers would be wrong?

> (Or does
> Firebug use the decompilation-based stuff? Does that stuff still work in
> JSD?)
What do you mean by "decompilation-based stuff"?

Honza
(In reply to Jan Honza Odvarko from comment #17)
> (In reply to Steve Fink [:sfink] from comment #16)
> > Would allowing these through JSD with the wrong line number (0) but the
> > "right" filename actually help? You would know that the script had been
> > called, but you wouldn't be able to set breakpoints or anything.
> I don't understand why breakpoints couldn't be set. Is that because the line
> numbers would be wrong?

Yes

> > (Or does
> > Firebug use the decompilation-based stuff? Does that stuff still work in
> > JSD?)
> What do you mean by "decompilation-based stuff"?

Passing jsdIScript.PCMAP_PRETTYPRINT into pcToLine/lineToPc. Does that still work? Does Firebug use it?
I use dojo tabbed contentpanels (57 to be exact) that get their content via a url.
The content of each is almost a complete page with its own JS and AJAX stuff.
All of the pages have 50 to 1000 lines of JS in them.
Dojo instants the HTML and, I presume, evals the JS.
So the file name should be the name of the file in the URL but how would JS know about that.
I would like to see the source line of the error and not a line of who knows what in the parent file as is happening now.
(In reply to Steve Fink [:sfink] from comment #18)
> Passing jsdIScript.PCMAP_PRETTYPRINT into pcToLine/lineToPc.
> Does Firebug use it?
Yes

> Does that still work?
Seems to be buggy, but not sure if the following report is about a problem in Firebug or JSD.
http://code.google.com/p/fbug/issues/detail?id=4646

Honza
Attachment #574954 - Flags: review?(timeless)
Assignee: general → nobody
JSD1 has been gone for ~3 years now. Please re-open if this bug is still present in DebuggerAPI versions of firebug or the devtools.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: