I just stumbled on something that could make a big difference in
conjunction with good line numbers. The thing that is time consuming in
resolving a runtime error is getting from page code back to our DOM. The
runtime errors are expressed in the page code's own variables, like:
widget is undefined on line 123
But the root cause is sure to be in the edbrowse DOM most of the time.
How do you bridge the gap in a methodical way rather than a painstaking
way with no standard way to go about it?
Apparently call stacks are available for the asking!
Here's an example from http://demos111.mootools.net/Fx.Slide
After an error occurs, page code is available from jdb in
document.scripts.
I ran one of these inside a try-catch and got:
try { eval(document.scripts[2].data)() } catch (e) { alert(e.stack) }
CSSStyleDeclaration.prototype.getPropertyValue@foo:1574
.getStyle@foo:2311
.getStyle/<@foo:2288
.getStyle@foo:2290
Element.getMany/<@foo:2624
$each@foo:1108
Element.getMany@foo:2623
.getStyles@foo:2335
Fx.Slide<.initialize@foo:4626
Class.Merge/merged@foo:461
Class/klass@foo:368
@foo:4
Element.Events.domready.add@foo:3728
Element.Methods.Events.addEvent@foo:2915
@foo:1
@foo:1
The constructions at the bottom are theirs, and the CSSStyleDeclaration at
the top is by me in startwindow and contains some sort of misphrasing.
Music to my ears, if I had known that a call stack was sitting there in e,
I would have used it a long time ago..
Kevin
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
