Problems with Breakpoint Properties



Other Applications
Venkman JS Debugger
15 years ago
14 years ago


(Reporter: Phil Schwartau, Assigned: Robert Ginda)


Windows NT

Firefox Tracking Flags

(Not tracked)



(2 attachments)



15 years ago
Using Mozilla trunk binary 2003042808 on WinNT4.0
Using Venkman version 0.9.68.

1.  Load the testcase I will attach below, in Mozilla and Venkman
2.  Venkman Pretty Print: OFF
3.  Set a breakpoint on line 35. It's the first line inside the brace of h():

                for (var i=0; i<UBOUND; i++)

4.  Right-click in Venkman to get the Breakpoint Properties dialog
5.  Set these properties:

                Enable breakpoint:              ON
                When triggered, execute:        COUNT = 500;
                Continue regardless of result:  ON
                Log result                      ON

6.  Single-click 'Apply', then 'Close'
7.  Right-click to bring up the Breakpoint Properties dialog again
8.  Observe: all your settings are still there
9.  Reload the test in Mozilla
10. Observe: you are now stopped on line 35
11. Right-click to bring up the Breakpoint Properties dialog again
12. Bug: all your breakpoint settings are gone!


|COUNT| is a global variable in the testcase that is incremented
in a double loop like this:

   for (var i=0; i<UBOUND; i++)
     for (var j=0; j<UBOUND; j++)

The value of |UBOUND| is 10, leading to a final value of 100 for |COUNT|.
By using the Breakpoint Properties dialog, we are trying to reset the 
initial value of |COUNT| from 0 to 500, leading to a final value of 600.

AFAIK, I don't have any preference settings in Venkman that should
cause my breakpoint properties to disappear. I am leaving Mozilla
and Venkman up the entire time I'm doing this: it's all happening
in a single session.

Note step 10, the fact that we actually stopped at the breakpoint, is
already a sign that the breakpoint properties have been lost, without
even bringing up the dialog to check. From bug 203699 comment 13:

------- Additional Comment_ #13 From Robert Ginda 2003-04-29 17:25 -------
The second thing is that the "Enable Breakpoint" option is actually supposed
to disable the breakpoint altogether.  "Continue regardless of result" is all 
you should have needed to check to keep venkman from actually *stopping* for
the breakpoint.  

We had "Continue regardless of result" set to ON, so we shouldn't even
have stopped at the breakpoint. The fact that we did stop shows that the
settings have been lost -

Comment 1

15 years ago
Created attachment 122410 [details]
HTML testcase

Comment 2

15 years ago
I notice that there are even more problems when running the testcase
off the Bugzilla server. Now I find I do not stop at the breakpoint
at all, and it changes from a 'B' to an 'F' (future breakpoint).

In the Loaded Scripts pane, it looks like the entire testcase is 
getting garbage-collected (?), leaving Venkman no choice but 'F'.
This did not happen when I ran the testcase locally!

Once again, all the breakpoint properties are lost -

Comment 3

15 years ago
Wow, never mind the breakpoint properties problem. No breakpoints
that I set in the above testcase get hit when I run it off the
Bugzilla server! In the Loaded Scripts view, you can see the 
testcase file duplicate briefly: there are two copies, and then one.
It looks like Venkman is loading the testcase from scratch and losing
all breakpoint settings.

I hope it's not some preference that I inadvertently have set -

Comment 4

15 years ago
Just tried using Venkman version 0.9.66 and got the same results:

1. Loading the testcase locally off my hard disk:
   a) Breakpoint properties are lost when we reload the testcase
   b) We stop at the breakpoint, which is highlighted by a red 'B'

2. Loading the testcase off the Bugzilla server
   a) Unable to stop at ANY breakpoint we set (never mind about properties)
   b) Breakpoints are changed by Venkman from 'B' to an 'F'

In each case, local or off the server, I see the testcase duplicate
briefly in the Loaded Scripts view when I reload it. There are briefly
two copies in Loaded Scripts, and then just one again -

I'm beginning to wonder if my installs of Venkman are corrupted somehow?
I'm getting them from, using a
Mozilla trunk binary 2003042808 on WinNT. When doing so, I occasionally
see "Error -201" when the install finishes. But I then I close Mozilla
completely, open it again, retry the install, and it succeeds (so it says).

Is there a way to clobber Venkman? I could try an install after that -

Comment 5

15 years ago
Same problems running the testcase on Linux off the Bugzilla server.
Here I'm using Mozilla trunk binary 2003042310 and Venkman 0.9.60.

Venkman does not stop on any breakpoint I set in the above testcase 
when I reload it in Mozilla. In Venkman, the Source Code view goes
completely grey, as if the whole testcase got garbage-collected.

I don't see the duplication I reported above in the Loaded Scripts
view, but it may simply be happening too fast for me to see. I do
see this: when I'm about to reload the testcase, I have the file
expanded in the Loaded Scripts view, so that I can see all four
functions in the treeview there. But after reloading, the treeview
collapses and looks the same as if I'd just loaded the testcase for
the very first time.

Comment 6

15 years ago
Created attachment 122416 [details]
HTML testcase using alert() instead of document.write()

Comment 7

15 years ago
Replacing the document.write() of the first testcase with alert()
didn't have any effect; I'm still having the same problems on both
my WinNT and Linux machines.

I keep staring at the testcases to see if there's a coding error
or HTML error, but I can't find it. I just can't figure it out -

Comment 8

15 years ago
There are two problems here.  The first is that future breakpoints don't work
properly if they come from urls that contain the "?" character.  That's because
I use, which converts its argument to a regular expression:


Thank you ECMA, may I have another.  I'm now using indexOf instead.

The second problem is that future breakpoint properties are distinct from hard
breakpoint properties.  If you modify settings on a hard breakpoint, the future
breakpoint will not see those changes.  So when you reload the file and get a
new hard breakpoint, your previous changes were lost.

I decided to make it so that if you change proeprties on a hard breakpoint, and
that hard breakpoint has an associated future breakpoint, then the future
breakpoint is updated with the changes.

Try venkman 0.9.69, and let me know what you think.

Comment 9

15 years ago
Tried Venkman 0.9.69, and now I'm getting a new problem on WinNT.
Whether loading the testcase off Bugzilla or off disk, I do this:

A. Expand the test file in the Loaded Scripts view
B. Double-click on function h() in the treeview
C. I now get an alertbox with this error message:

      "x-jsd is not a registered protocol"

D. No further progress is possible -

On Linux, I don't get this problem with Venkman 0.9.69. However,
once I set a breakpoint in function h() (off the Buzilla server),
the Source Code view turns into grey background when we hit the
breakpoint. We can tell we're stopped: the Continue arrow is green,
and we can see the stack of the testcase in the Call Stack view:


But we cannot see anything in the Source Code view once we're stopped.
It's in its initial grey state, and remains so as we step through the
code. This is with Pretty Print off. When Pretty Print is on, there is
no problem with the Source Code view on Linux.

Comment 10

15 years ago
OK, Venkman 0.9.69 is working on WinNT now. My problem was due
to .xpi install errors such as those noted above in Comment #4.
Once I did a clobber-install, I was all set.

Rob also explained to me that we need to have Pretty Print on
for a testcase like this, in which all the code executes while
the page is loading. 

So - with Pretty Print on, we now get the expected results from
the original steps to reproduce above. On both Linux and WinNT,
the breakpoint properties now correctly persist upon reloading
the testcase, and produce the desired effect: 

1. We don't stop at the breakpoint
   (because "Continue regardless of result" is set to ON)

2. The final value of |COUNT| is 600 instead of 100.

Yay! But there is one proviso: all this works only with the
SECOND testcase above, which outputs |COUNT| in an alert()
rather than document.write(). 

With the first testcase, the final value of |COUNT| is 100,
and the breakpoint properties are all lost. In fact, Venkman
will not stop at any breakpoint, even if Pretty Print is on.

See bug 114461, " clobbers JS context"
Calling document.write() implicitly calls,
so this may be what's happening - is that right?

Comment 11

15 years ago
There were a few other places where I had used search() instead of indexOf(). 
This could make it appear as though you had a breakpoint set, even though there
wasn't one there.  Please try 0.9.70, the first testcase appears to work for me
in it.

Comment 12

15 years ago
Venkman 0.9.70 seems to have regressed on both WinNT and Linux.
On both machines, and in both testcases, Venkman is not stopping
at any breakpoint I set (never mind about breakpoint properties).

That is like the situation I was in at Comment #7. However, now
the problem also occurs when I run the testcases off my hard disk.
It's not just occurring off the Bugzilla server -

Here's what I'm seeing, off disk or Bugzilla:

1. Load either test
2. Set a breakpoint in function h()
3. We see a red 'B' in the Source Code view
4. We see the breakpoint in the Breakpoints view
5. Reload the testcase in Mozilla
6. Venkman does not stop at the breakpoint
7. The breakpoint disappears from the Breakpoints view
8. The breakpoint still appears as a red 'B' in the Source Code view
9. However, we cannot interact with it via the right-context menu

I'm using trunk Mozilla builds with these dates:

WinNT: 2003-04-28  rv:1.4b
Linux: 2003-04-23  rv:1.4b

Comment 13

15 years ago
Rob found the trouble: I had Pretty Print set to ON when I
was trying to set the breakpoints via the Source Code view.
This is not possible. 

My confusion arose from Comment #10:

> we need to have Pretty Print on for a testcase like this,
> in which all the code executes while the page is loading. 

The real story was that for such a script:

1. We needed to have Pretty Print OFF to set the breakpoint
2. We needed to have Pretty Print ON to see Venkman stop there

Rob has fixed this dichotomy in the latest version of Venkman
(0.9.71). Now we can leave Pretty Print off the entire time,
even for scripts like this, which run as the page is loading.
This is a wonderful improvement!

Furthermore, this bug is now fixed. On both Linux and WinNT,
my breakpoint properties persist on both the testcases above, 
no matter how many times I reload them in Mozilla. I can also
reopen the Breakpoint Properties dialog and change my settings.
And both tests work whether loaded from disk or from Bugzilla.

Using Mozilla trunk binaries 2003-05-05 on Linux and WinNT.
Using Venkman versions 0.9.70 and 0.9.71 on each platform.

Comment 14

15 years ago
marking fixed
Last Resolved: 15 years ago
Resolution: --- → FIXED
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.