200591 - File Options > Don't Debug Eval/Timeouts isn't working

Status: VERIFIED FIXED

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

Description

[Phil Schwartau]

Using Mozilla trunk 2003033105 on WinNT. Using Venkman version 0.9.57

STEPS TO REPRODUCE
1. Bring up Mozilla
2. Bring up Venkman
3. Load the test HTML file I will attach below
4. In Venkman, right-click on the file in the Loaded Scripts view
5. Select "File Options"
6. Select "Don't Debug Eval/Timeouts"
7. Hit the Stop button in Venkman
8. Bug: the yellow line appears in the Source Code view, and we
   are now stopped in the setInterval() code of the test file.


Expected Results: Venkman shouldn't stop in any setTimeout()
                  or setInterval() code in this file


CONTINUATION ON THE ABOVE
9.  Hit the Continue button in Venkman to break out of the setInterval() 
10. Reload the test file in Mozilla
11. Right-click on the file in the Venkman Loaded Scripts view
12. Note the "Don't Debug Eval/Timeouts" selection has persisted
13. Hit the Stop button in Venkman
14. Bug: once again we are stopped in the setInterval() code

Comment 1

[Phil Schwartau]

Attachment: Testcase

Comment 2

[Robert Ginda]

Attachment: Don't remove disabled frames from the call stack

So, we only pay attention to the "don't debug" flag of the top stack frame.  In
addition to that, the jsd code *removes* any frames marked "don't debug" from
the stack chain.

To fix this, the front end code will need to check to see if the bottom stack
frame is an eval/timeout (and that these "transients" are disabled.)  Before it
can do that though, jsd needs to stop hiding these disabled frames.  This patch
takes care of leaving disabled frames in the stack trace.

Comment 3

[Robert Ginda]

Comment on attachment 120655 [details] [diff] [review]
Don't remove disabled frames from the call stack

actually, I want to think about this one a little more.  This might be the
right way, but maybe not.

Comment 4

[Robert Ginda]

Attachment: new patch

Rather than leave the determination up to the front end, this patch decides
whether or not to invoke the call hook right in the jsd code.  My big concern
is that I'll find out later that this is going to cause other problems, like if
XBL javascript were to call into web content, or something.  To hedge against
this I exposed a few new flags that can be used to get the old behavior back in
a hurry.  It's a bit more to think about, but I'm more comfortable doing it
this way, especially if 1.4 is going to be a long-lived branch.

I also added some versioning information to the interface, so clients know who
they're dealing with.

Comment 5

[Robert Ginda]

Comment on attachment 120879 [details] [diff] [review]
new patch

brendan: got time for another review?

Comment 6

[Brendan Eich [:brendan]]

Comment on attachment 120879 [details] [diff] [review]
new patch

rubbery r=brendan, I'm in a hurry and you're the jsd guru.

/be

Comment 7

[Robert Ginda]

checked in

Comment 8

[Phil Schwartau]

Verified FIXED.

Using Mozilla trunk builds on Linux and WinNT dated 2003-04-23.
File Options > Don't Debug Eval/Timeouts now works fine on the
attached testcase. We can toggle it on and off after the test
has loaded, to control whether we do or do not stop in the
setInterval() loop.