Bug 9686 - [Drosera] Need the ability to break into Drosera on Javascript exceptions
Summary: [Drosera] Need the ability to break into Drosera on Javascript exceptions
Status: CLOSED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P4 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-01 22:37 PDT by Eric Seidel (no email)
Modified: 2008-05-17 09:55 PDT (History)
1 user (show)

See Also:


Attachments
Work-in-progress patch (8.26 KB, patch)
2006-07-12 14:29 PDT, Mark Rowe (bdash)
no flags Details | Formatted Diff | Diff
Patch (16.92 KB, patch)
2006-07-13 02:10 PDT, Mark Rowe (bdash)
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2006-07-01 22:37:35 PDT
Need the ability to break into Drosera on Javascript exceptions
Comment 1 Eric Seidel (no email) 2006-07-01 22:38:05 PDT
It should automatically bring Drosera forward, like FireBug does.  It would be even better if this were integrated into the app directly...
Comment 2 Mark Rowe (bdash) 2006-07-12 14:29:07 PDT
Created attachment 9418 [details]
Work-in-progress patch

This work in progress patch is almost fully-functional.  I'm quite certain that the code in JSCore hooks in to the wrong place in the execution to catch exceptions, but I couldn't find a better bottleneck.  The downside of having debugExceptionIfNeeded called from the KJS_CHECKEXCEPTION macro is that it is called for each stack frame the exception propogates out of.  I've hacked around that by stashing a property on the object to indicate it has been dealt with.  Needless to say, that isn't a good solution.  I'm looking for pointers as to a better place to hook into exceptions being raised that can avoid the need for this type of state to be kept.

The Drosera part of the patch adds the bare minimal behaviour.  It is probably desirable to log exceptions to the console window, but I think that should be dealt with in a separate patch.
Comment 3 Mark Rowe (bdash) 2006-07-12 15:58:33 PDT
Darin suggested that I may be able to achieve the same end result without implementing the exception/exceptionWasRaised method.  The WebScriptCallFrame passed to webView:willExecuteStatement:sourceId:line:forWebFrame: and webView:willLeaveCallFrame:sourceId:line:forWebFrame: knows if an exception has been raised, and this information can be used to determine when to pause the debugger.  The problem is that this will break at the next statement that executes after the exception is raised, or while exiting the current call frame.  In the case of an exception outside of the body of a function, neither of these conditions occurs.  The end result is that an exception outside of the body of a function is not trapped.  A secondary issue is that due to the way Drosera tracks stack frames, the JS code that controls pausing does not have access to the exception object and thus cannot retrieve the line number where the exception was raised.

This approach seems better due to it limiting the changes required to Drosera, but it's not clear to me how to work around the limitations.
Comment 4 Mark Rowe (bdash) 2006-07-13 02:10:48 PDT
Created attachment 9425 [details]
Patch

I've updated the patch based on feedback from Maciej on IRC.  The exception callback is now called for all exceptions rather than only Object instances, and the KJS::Debugger tracks which exceptions it has seen rather than KJS::Node setting a magical property on the exception object.
Comment 5 Maciej Stachowiak 2006-07-13 20:47:19 PDT
Comment on attachment 9425 [details]
Patch

r=me
Comment 6 Timothy Hatcher 2006-07-23 23:01:08 PDT
Landed in r15593.
Comment 7 Timothy Hatcher 2006-07-30 23:09:11 PDT
Landed the Drosera part in r15701
Comment 8 Timothy Hatcher 2008-05-17 09:55:53 PDT
Closing since Drosera has been replaced by the new Web Inspector debugger. Moving to the New Bugs component so the Drosera component can be closed and removed.