Bug 9686 – [Drosera] Need the ability to break into Drosera on Javascript exceptions

• Status: CLOSED
• Resolution: FIXED
• Component: New Bugs

[Eric Seidel (no email)]

Need the ability to break into Drosera on Javascript exceptions

[Eric Seidel (no email)]

It should automatically bring Drosera forward, like FireBug does.  It would be even better if this were integrated into the app directly...

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

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.

[Maciej Stachowiak]

Comment on attachment 9425 [details]
Patch

r=me

[Timothy Hatcher]

Landed in r15593.

[Timothy Hatcher]

Landed the Drosera part in r15701

[Timothy Hatcher]

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.