Closed Bug 110312 Opened 23 years ago Closed 23 years ago

Files with no functions aren't displayed in the debugger

Categories

(Other Applications Graveyard :: Venkman JS Debugger, defect, P1)

Product:
Other Applications Graveyard
Component:
Venkman JS Debugger
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: pschwartau, Assigned: rginda)

References

(
URL
)

Details

Attachments

(3 files)

Testcase without function definition (fails to show up in venkman)
256 bytes, text/html
Details
Testcase with function definition (shows up in Venkman)
275 bytes, text/html
Details
patch
32.13 KB, patch
Details | Diff | Splinter Review 
Not all included <SCRIPT> occurs at <HEAD> or <BODY> level. Sometimes it
occurs within lower-level HTML elements, as at the site given above:

<div align="left">
  <script LANGUAGE="JavaScript1.2" SRC="HM_Loader.js" TYPE='text/javascript'>
  </SCRIPT>
</div>


I would like to debug the JS file "HM_Loader.js", but I can't see it
in the JS Debugger. Would it be possible to display such JS files?

What would happen if "HM_Loader.js" had been placed in-line?
We would have seen it in the Debugger then, right?
I've experimented by downloading all the HTML and JS source.
When all the JS is placed in-line within the <DIV>, as in:

<div align="left">
  <script LANGUAGE="JavaScript1.2" TYPE='text/javascript'>
          ... all the script here, in-line ...
  </SCRIPT>
</div>

I DO see it all in the JS Debugger.

rginda informs me that it shouldn't matter whether the script is
in-line or external: you should see it regardless, even though it's
inside a lower-level HTML element like a <DIV>.
When you load the original URL, what you do see in the JS Debugger
are these two files:

                        the parent HTML file
                        HM_ScriptDOM.js


Note that HM_ScriptDOM.js is document.written by the HM_Loader.js file
above! In fact, HM_Loader.js writes a total of two JS files into the HTML:

                        HM_ScriptDOM.js
                        HM_Arrays.js


All these JS files may be found at: 

          view-source:http://michael-nuhn.de/HM_Loader.js
          view-source:http://michael-nuhn.de/HM_ScriptDOM.js
          view-source:http://michael-nuhn.de/HM_Arrays.js


The fact that the JS Debugger does show HM_ScriptDOM.js proves that
it IS loading the HM_Loader.js file, but for some reason HM_Loader.js
gets garbage-collected, according to rginda, and so can't be seen.

Note: HM_Loader.js, HM_ScriptDOM.js contain function declarations;
      HM_Arrays.js does not - 
The site is being evangelized in bug 110287.  As a result the files on that page
are subject (hopefully) to change soon.

For reference, note that the version of HierMenus being used is 
/*HM_Loader.js
* by Peter Belesis. v4.0.8 010405

That version of hiermenus may be permanently found here:
http://www.webreference.com/dhtml/column51/HM4-0-8.zip
I'm not sure yet what the problem is here, but it could be a bug in some native
code, setting P1.
Status: NEW → ASSIGNED
Priority: -- → P1
I'm seeing the same thing, i need to add at least one function declaration for a
file to show up in venkman. I just tried in Mozilla 0.9.7 (200112012), and it
has the bug too.
Target Milestone: --- → mozilla0.9.9
Summary: JS Debugger should show <SCRIPT> within <DIVS>, etc. (?) → Files with no functions aren't displayed in the debugger
I'm thinking that this bug is INVALID.  I put some dumps in the realizeScript
and unrealizeScript routines in venkman...
vnk: new scriptrecord: function  in
<http://bugzilla.mozilla.org/attachment.cgi?id=64146&action=view>
    var whatever = 1;
    whatever++;
vnk: remove scriptrecord: function  in
<http://bugzilla.mozilla.org/attachment.cgi?id=64146&action=view>

What that means to me is that the script was loaded, executed, and garbage
collected.  The lack of functions means that there is no reason for the engine
to hold on to the script, and it just goes away.

If you want to break in this code, you'll need to use ``fbreak''.  Some day RSN
you'll be able to load any URL in venkman, and click on the margin to set a
future breakpoint, and this won't seem like much of a hassle.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Rob: what would happen if all the function definitions were stored
in one file, and there were only function calls in another file, e.g.:


var pref = getUserPref();

if (pref)
{
 loadTables(pref);
}
else
{
 var err = getErrMsg();
 warnUser(err);
}


1. Are you saying that we won't be able to see any of this in the debugger?

2. But if this second file just had a dummy function f(){}, we'd see it?

3. If the answer to the above is "yes", then could the debugger artificially
   add (and hide) such a dummy function to the file for that purpose?

4. Does Venkman still do the following, from:
   http://www.mozilla.org/projects/venkman/venkman-walkthrough.html#script-view
 
  > The "special" function name __toplevel__ is displayed for scripts
  > that are not part of an actual function.


5. Even if we could see the calling file above, would we be able to
   break on every line we'd like to? For instance, | if (pref) | ? 
   Or would we just see it and not be able to break on it?
According to what I know, the answer to 5) above is "No".
Even today, if a file has functions in it (so we can see it),
we cannot set a breakpoint on a statement like |if (pref)| 
unless it occurs inside a function. If it occurs at top-level
we can't set a breakpoint on it. Is that correct? 

From a user's point of view, I want to be able to break on 
statements whether they occur inside or outside functions.
Should I file another bug on that, or is that a non-starter?
Note: bug 111352 has a similar-sounding description, 
"Breakpoints cannot be set for some valid javascript lines in switch statement",

but AFAICT, the lines in question in that bug are inside a function,
thus do not address the question I've raised above -
The issue here is that there is nothing to hold the script around, so it gets
garbage collected.

If I have Script A, which calls a few functions in Script B but defines no
functions of it's own, then once Script A has *completed* it is of no further
use to the engine.  It is impossible for any other script to refer to it,
because it has no "public" functions.  Any top-level variables it declares are
created on the global object, and exist after script completion, but the script
object itself goes away.  When scripts objects are finalized by the engine,
Venkman removes them from the UI.

so...

1. You'll see the script which defines getUserPref, loadTables, getErrMsg, and
warnUser... you won't see you sample usage if these functions if they are
defined in a seperate file.

2. Yes.

3. No, let's not go there.

4. Yes, Venkman still does that.  __toplevel__ scripts are rooted by the
functions that are defined by them.  If a __toplevel__ script has no functions
to root it, then it is garbage collected right after execution.

5. By the time you saw it, it would have already completed and been garbage
collected, you would not be able to set a breakpoint, only a fbreak.

I'll repoen this... something needs to be done... I'm just not sure what.

I could *not* remove entries from the script view when they are finalized by the
engine, but that would probably confuse users in new ways.

I think the real issue here is that the scripts view doesn't show what you think
it does.  I'll eventually add a list of open windows to the project view, and
under each of the window I'll list <script> tags I find there, *then* you'll
have the list I think you're looking for.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Status: REOPENED → ASSIGNED
Targeting to mozilla1.0.1, sooner if things go well.
Target Milestone: mozilla0.9.9 → mozilla1.0.1
I just added a "Windows" entry to the project view.
It looks like...
  + Windows
    + navigator.xul
    | + Files
    | | + (<script> tags found in navitagor.xul ...)
    | + foo.html (file loaded in the active tab of this nav instance.)
    | | + Files
    | | | + (<script> tags found in foo.html ...)
    | | + bar.html (file loaded in a frame of foo.html.)
    | | + (other frames ...)
    | + (other html files loaded in this nav instance, such as sidebar tabs.)
    + (other xul windows currently open.)

Users can double click on any of the window/file objects to display it in the
source view, even if that file is not currently in use by the javascript engine.
 If the file is not loaded, the "executable" markers are not shown in the
margin, and clicking in a margin sets a future breakpoint.

A "Find URL" entry has been added to the project context menu, and the
"find-url" command has been exposed to the console.  If you want to view some
file not attached to a window, and not loaded by the js engine, use "find-url
<url>" to load it in the source view.  You can then set future breakpoints by
clicking in the margin.

URLs are *not* refreshed when the page changes, to refresh the list of urls
loaded by a window, close and open the parent node.  I'll fix this later,
probably post 1.0.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0.1 → mozilla0.9.9
Attached patch patch — — Splinter Review 
This is what the changes look like.
This seems to work well. At the original site, http://michael-nuhn.de/,
I can now use the Windows entry to the Project View to see the files
I couldn't see before. Currently I see all the site's JS files:

                        HM_Loader.js
                        HM_Arrays.js
                        HM_ScriptDOM.js


As before, HM_ScriptDOM.js contain function declarations, and so 
can also be seen in the Script View, as it always could.

Similar behavior holds true on Peter's testcases above. Without a 
function definition in "attachment.cgi", one can now see it under
the Windows entry of the Project View. With a function definition,
one can see it there and in the Scripts View as well.

Let me mark this Verified FIXED, then -
Using Mozilla trunk binary 2002022009 on WinNT
Status: RESOLVED → VERIFIED
*** Bug 107898 has been marked as a duplicate of this bug. ***
Product: Core → Other Applications
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: