JavaScript Debugger
Peter Kelly
pmk at kde.org
Wed Mar 5 12:25:23 GMT 2003
Hi David,
Thanks for your detailed reply :)
Some of this stuff may take me a while to get to... but I've got a few
ideas about some of these things which can hopefully be implemented in the
near future. I'm CC'ing kfm-devel as others may have some comments too.
On Tue, 4 Mar 2003, David Joham wrote:
>
> Wow. *very* nice! It looks like most of the functionality is there for a very cool debugger. Would
> you like some feedback on UI now and maybe a couple of feature requests? Great, I'm glad you
> asked! :)
>
> It would be nice to have a visible gutter to the left of the line numbers that indicates that you
> can click there to set a breakpoint. I didn't know you could do that until I just randomly tried
> it and it worked. A gutter would remove all doubt. I would prefer a single click rather than a
> double click in the gutter.
Currently the debugger is using a QListView to display the code, which
doesn't really support extra display options like this. Admittedly it's
not really the best thing for displaying code. I'm thinking of switching
to a custom widget for this which will give a lot more flexibility and
allow for what you described (as with the breakpoint/current line
hilighting described below).
>
> The debugger lets you set breakpoints on non-javascript lines. I'm not sure there's much you could
> do about that (Mozilla does this as well) but if it's possible to avoid this situation, it would
> be helpful.
Not really very easy to do as currently the debugger has no knowledge of
the structure of the code. It could potentially be done by analysing the
parse tree generated by kjs, but this would be fairly complex to implement
and IMHO not worth the effort.
>
> Would it be possible to have a list of all of your current breakpoints?
>
> It would be nice if the breakpoint line was colored all the way across the debugger instead of
> just having the dot on the left. IMNSHO, it makes the breakpoints much easier to find.
Sounds reasonable. Possible a "breakpoints" menu containing one item per
breakpoint.
>
> Along the same lines, would it be possible to perminantly highlight the currently executing line
> in the debugger with a color other than the standard highlight color? If you're stepping through
> and accidently highlight a line other than the currently executing line, the highlight moves to
> that line and you loose track of the line where you are going to execute next.
>
> It would be nice if the debugger would bring itself to focus when a breakpoint was hit.
>
> It would be nice if the icon for the debugger was different than the one for Konq. With the icons
> being the same, it makes the debugger harder to find in the task list. The icon you use for the
> breakpoint would be ideal.
>
> It would be nice if "step" said "step into" to be more clear as to what the button did.
Nicer icons would certainly be good. I'd like to use the icons from the
debugger in kdevelop. These are not currently part of kdelibs though so
I'll look into what's involved in using those.
>
> Keyboad shortcuts (F8 for next, etc) would be really nice.
Agreed.
>
> It would *really* be nice if the javascript console spit out any javascript errors that it
> encountered. This would be similar to Mozilla's js console which is very useful. For example, if
> you have something like var x = documennt.getElementById("foo").value, mozilla's javascript
> console will spit out
> Error: documennt is not defined
> Source File: file:///home/kde3/tmp/test.html
> Line: 19
> Usually, this information alone is enough for me to find the problem and fix it - eliminating the
> need to actually step through the code.
If you have javascript error reporting enabled you will see an error
dialog giving the error details. This is better in some cases as you may
want to break at that point. But it could probably print out the error as
well when the code finished executing (perhaps with a backtrace).
>
> It seems you can confuse the debugger if you tell it to do something it doesn't know how to do.
> For example, if you load an HTML page and open the debugger, you don't have any variables defined
> yet, which is to be expected. However, if you go to the javascript console and type "alert(x)" you
> get dumped to a new line that just says "Exception:". If you hit enter trying to get out, all you
> get is "undefined" each time you hit enter. This doesn't affect the debugger at all (it will still
> catch breakpoints later on), but it can be confusing.
Odd. I'll investigate.
>
> It would be nice if after every javascript call, you could refresh the browser. For example, if
Agreed.
> you have the following code and are stepping through it, the browser window won't be updated until
> the end of the function which can be confusing.
> <script type="text/javascript">
> function go() {
> for (intLoop=0; intLoop < 10; intLoop++){
> document.getElementById("id").value = intLoop;
> }
> }
> </script>
>
> If you are in the loop above and type "alert(intLoop)", you do get an alert box and the browser
> window redraws. You also get an "undefined" spit out to the console.
>
> I also noticed in the above code that if I have a breakpoint set on the document.getElementById
> line and do something stupid like type "print 'x'" at the console, it seems to totally send the
> javascript system into the weeds. I get "Exception: SyntaxError: Parse error at line 2". At that
> point, we're basically in an unrecoverable state. I can't continue or step. Would wrapping all of
> the code being manually typed into the console in a try/catch block behind the scenes fix this? I
> tried wrapping it manually (try{print 'x';}catch(e){alert('foo');}) but it didn't help.
>
> If you've got a breakpoint in the code above and you close the debugger, it magically decides to
> come back to life each time the breakpoint is hit under the covers. Amusing :)
>
> It would be really nice if there was the way to set watches or to view the local/global variables.
> The only way to see the values now is to use alert statements which is OK, but not optimal.
> Ideally, I could hover the mouse over a variable and it would spit the value out to a little
> tooltip, but that's asking a lot.
>
> Wow. That's quite a list. As you can tell, I've been wanting this in Konq for a long time. One
> thing I might do if you wouldn't mind would be to get in contact with the Quanta developers once
> we're finished working on this. I'll bet they would love to have an integrated javascript debugger
> built into their tool. Any objections?
>
> I was able to find one reproducable crash. Here are the steps to reproduce:
>
> browse to an html file on your local file system
> open the debugger
> hit the "home" button in konq
> browse to any html file on your local file system again
>
> this backtrace is created:
> 0x411f3739 in wait4 () from /lib/i686/libc.so.6
> #0 0x411f3739 in wait4 () from /lib/i686/libc.so.6
> #1 0x41270340 in sys_sigabbrev () from /lib/i686/libc.so.6
> #2 0x41043a73 in waitpid () from /lib/i686/libpthread.so.0
> #3 0x407d0a97 in KCrash::defaultCrashHandler(int) ()
> from /home/kde3/installs/kde/lib/libkdecore.so.4
>
> Lastly, it would be nice to get our names added to the about->konqueror credits list once we get
> this finished. Any idea how to do that?
>
> Thanks again for all your work and help on this. Please let me know if/when you can implement any
> of these suggestions. I'll be happy to help out further...
>
> Best regards,
>
> David
>
>
>
>
>
> --- Peter Kelly <pmk at kde.org> wrote:
> > These problems should both be fixed now. Try again with the latest code
> > and see how you go.
> >
> > On Sun, 23 Feb 2003, David Joham wrote:
> >
> > > Hello!
> > >
> > > First, I'd like to tell you that you're my personal hero for working on the Konq JavaScript
> > > debugger. One of the few reasons I keep Mozilla around it its very nice debugging
> > capabilities.
> > >
> > > I'd like to help you out in any way I can while you're building this. I do a lot of rather
> > complex
> > > JavaScript work on one of my projects, XML for <SCRIPT> (xmljs.sourceforge.net).
> > >
> > > At the moment, I'm struggling to get the debugger to work at all. Here's what I've tried so
> > far.
> > >
> > > 1) attempt 1
> > >
> > > a)I've gone to xmljs.sf.net and selected test suite from the navigation on the left.
> > > b)I then opened up the debugger
> > > c)I notice in the debugger part of my HTML code shows up, but not all. It looks like it only
> > loads
> > > 95 lines for some reason. If I repeat this process, it still only loads 95 lines.
> > > d)I then open up the DOM test suite
> > > e)In the debugger, I set "break at next statement"
> > > e)I then click the "launch tests" command inside the DOM test suite
> > > f)I'm rewarded with a surprisingly small back trace as a result :)
> > >
> > > 0x411ee739 in wait4 () from /lib/i686/libc.so.6
> > > #0 0x411ee739 in wait4 () from /lib/i686/libc.so.6
> > > #1 0x4126b340 in sys_sigabbrev () from /lib/i686/libc.so.6
> > > #2 0x4103ea73 in waitpid () from /lib/i686/libpthread.so.0
> > > #3 0x407cbcd7 in KCrash::defaultCrashHandler(int) ()
> > > from /home/kde3/installs/kde/lib/libkdecore.so.4
> > >
> > > 2) Attempt 2
> > >
> > > a) create a tiny web page that includes a small amount of javascript
> > > b) navigate to the page on local filesystem
> > > c) launch debugger
> > > d) notice no code shows up in the debugger :(
> > > e) set break at next statement
> > > f) invoke the JavaScript code
> > > g) the debugger traps the call and I get a call stack. Yea!
> > > h) Still no code showing in the debugger. Only line numbers in the call stack. Drat!
> > >
> > > I've attached a screenshot of what I'm seeing with the debugger on the second case as well as
> > the
> > > code I'm using. Perhaps I'm doing something wrong?
> > >
> > > There is one major difference between #1 and #2. #1 uses scripts referenced from outside the
> > html
> > > page while #2 has the script embedded in the html page. I don't know if that would make any
> > > difference at all, but I thought I would mention it.
> > >
> > > I'm using kdelibs and kdebase compiled from HEAD as of last night (22Feb) so I think I have
> > the
> > > last code.
> > >
> > > I also have some time to spend on this if you would like any help tracking this down and
> > improving
> > > the debugger. I would dearly love to get this working as good or better than Mozilla's.
> > >
> > > Best regards,
> > >
> > > David Joham
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - forms, calculators, tips, more
> > > http://taxes.yahoo.com/
> >
> > --
> > Peter Kelly
> > pmk at kde.org
> >
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
>
--
Peter Kelly
pmk at kde.org
More information about the kfm-devel
mailing list