This is great!
dbcss can help in this regard, dumps lots of information to /tmp/css
If I make a list of all of the new debugging functionality, can you tell
me if I'm missing any?
dber - you toggle this from the edbrowse command line
dbcss - is this a toggle also?
^> - the file redirect to your filesystem
showscripts - list all scripts
searchscripts - searches all scripts for a string
debugEvent - toggles diagnostic messages about events - to get this, you
set the boolean variable to true and recompile
debugClone - you also enable this by recompiling
startwindow
demin
aloop
jdb
db#
And on this subject, there's something else you implemented recently and I
haven't taken advantage of it yet. It's the hex prefixes that show when
event handler code fails, usually near the end of the output after the
regular .js files have finished. Such as,
error in f575d3.ontimer()
It seems like excellent information, so how would you go about cross
referencing? Can we go from this message, to a key where
you can find out that f575d3 is a certain element? And then from that
point, maybe the element has an obscure string on it that you can look for
with searchscripts(), or you can get your bearings based on f575d3 and its
position in the tree.
It seems like a getElementsByEventListener("ontimer") would be useful.
That would be another way of narrowing it down. "I know from the error
message that a timer fails, so now I have the result set of five elements
that listen for this. It must be one of these." This could be either
another getElements function or maybe there is something among the
selector syntax to do it!
thanks
Kevin
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev