[dojo-contributors] library-specific debugger extensions

Mike Wilcox mike at mikewilcox.net
Wed Mar 24 14:39:53 EDT 2010

I wrote a blog post and with the help of a SitePen colleague, wrote a script for "fixing" the Webkit inspector.

Of particular annoyance is that Webkit shows you every dojo resource that loaded and it's mime type. This clutters the console unnecessarily. Obviously, this could be an option to turn off. Look at the Inspector with Google Wave. Jeez.

You can do a little bit of hacking to the console object, but a vast majority of the Inspector's code, while in JavaScript, is hidden behind the browser's C code. It would be great to have an API to access the JS as well as the CSS. We can't change any appearances either, and part of my hack is to allow different panel sizes and the ability to change text size, like if you are doing a presentation for example. This API would be great, since my hack gets wiped out any time you update Safari.

A ReCSS would be nice, though WebKit reloads so fast you almost don't need it. Some apps still take a while though.

But my Number One annoyance with Inspector (which I could not fix):
***You can't refresh the page with command-r if the console is it's own window and in focus***.

I know this isn't really JS Library specific, but I've been wanting to tell WebKit of these things for a while and have simply procrastinated.

Adam, I like the idea of (optionally) skipping over anonymous or certain functions.

How about a mechanism that loads library files into the DB for faster reload and execution? Just thinking out loud. Maybe you could have checkboxes by those files in the Resources view. I'm sure the browser cache mechanism does this to some degree, but when you develop, you usually need that to be off. There ya go.... Targeted Caching. You're welcome! No payment necessary!

Mike Wilcox

On Mar 24, 2010, at 12:56 PM, Adam Peller wrote:

> Patrick Mueller, a colleague of mine at IBM, is looking at some
> debugging improvements to webkit that might help Dojo.  He posted to
> dojo-interest, and I'd like to encourage you all to give him some
> feedback.  We could initiate him into contrib for this if that makes
> sense, but I thought it might be easier to get feedback from the
> larger community and try having the discussion on dojo-interest
> (please direct replies there)
> http://n3.nabble.com/library-specific-debugger-extensions-tp453684ef33424.html
> Initially, we thought of hiding the 'goop' in the stack that comes
> with closure tricks and stepping through code like dojo.connect,
> topics, declare, Deferred...  Perhaps some notation could make this
> possible in a library-independent way.  Additional abstractions for
> the toolkit-specific concepts might be useful, tracking module
> loading, connections, callbacks, though it's hard to make a case for
> putting these directly in the debugger.  That's where some extension
> mechanism might make more sense, and many of these tools might even be
> possible to write in pure js given the right hooks.  What other
> enhancements might be useful?  What other blockers do people run into
> debugging with the existing implementation?
> Also, he submitted an interesting hack to provide better function
> display info using the displayName trick, though only for Webkit-based
> browsers:
> http://bugs.dojotoolkit.org/ticket/10852
> -Adam
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list