Files with no functions aren't displayed in the debugger

VERIFIED FIXED in mozilla0.9.9


Other Applications
Venkman JS Debugger
17 years ago
14 years ago


(Reporter: Phil Schwartau, Assigned: Robert Ginda)



Firefox Tracking Flags

(Not tracked)




(3 attachments)



17 years ago
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'>

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?

Comment 1

17 years ago
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 ...

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>.

Comment 2

17 years ago
When you load the original URL, what you do see in the JS Debugger
are these two files:

                        the parent HTML file

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:


All these JS files may be found at: 


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 - 

Comment 3

17 years ago
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 
* by Peter Belesis. v4.0.8 010405

That version of hiermenus may be permanently found here:

Comment 4

17 years ago
I'm not sure yet what the problem is here, but it could be a bug in some native
code, setting P1.
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.
Created attachment 64146 [details]
Testcase without function definition (fails to show up in venkman)
Created attachment 64147 [details]
Testcase with function definition (shows up in Venkman)


17 years ago
Target Milestone: --- → mozilla0.9.9


17 years ago
Summary: JS Debugger should show <SCRIPT> within <DIVS>, etc. (?) → Files with no functions aren't displayed in the debugger

Comment 8

17 years ago
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
    var whatever = 1;
vnk: remove scriptrecord: function  in

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.
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 9

17 years ago
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)
 var err = getErrMsg();

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:
  > 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?

Comment 10

17 years ago
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?

Comment 11

17 years ago
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 -

Comment 12

17 years ago
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.


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.

Resolution: INVALID → ---


17 years ago

Comment 13

17 years ago
Targeting to mozilla1.0.1, sooner if things go well.
Target Milestone: mozilla0.9.9 → mozilla1.0.1

Comment 14

17 years ago
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.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0.1 → mozilla0.9.9

Comment 15

17 years ago
Created attachment 70476 [details] [diff] [review]

This is what the changes look like.

Comment 16

17 years ago
This seems to work well. At the original site,,
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:


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

Comment 17

16 years ago
*** Bug 107898 has been marked as a duplicate of this bug. ***
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.