204341 - Problems with Breakpoint Properties

Status: RESOLVED FIXED

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

Description

[Phil Schwartau]

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

STEPS TO REPRODUCE
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!


NOTES:

|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++)
     {
       COUNT++;
     }
   }

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

[Phil Schwartau]

Attachment: HTML testcase

Comment 2

[Phil Schwartau]

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

[Phil Schwartau]

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

[Phil Schwartau]

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 http://www.hacksrus.com/~ginda/venkman/, 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

[Phil Schwartau]

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

[Phil Schwartau]

Attachment: HTML testcase using alert() instead of document.write()

Comment 7

[Phil Schwartau]

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

[Robert Ginda]

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 String.prototype.search, which converts its argument to a regular expression:

js>
"http://bugzilla.mozilla.org/attachment.cgi?id=122410&action=view".search("http://bugzilla.mozilla.org/attachment.cgi?id=122410&action=view")
-1

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

[Phil Schwartau]

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:

                       h
                       g
                       f
                       test
                       __toplevel__


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

[Phil Schwartau]

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, "document.open() clobbers JS context"
Calling document.write() implicitly calls document.open(),
so this may be what's happening - is that right?

Comment 11

[Robert Ginda]

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

[Phil Schwartau]

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

[Phil Schwartau]

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

[Robert Ginda]

marking fixed