Venkman planning for Gecko 1.9
Alex Vincent
significantly on the trunk. Unfortunately, development on the JavaScript
Debugger has not kept pace - the code has "bitrotted" significantly, and
introduced significant bugs.
This is a serious problem. It's equally serious that no one is hacking
on it. I've found it to be a very useful tool for working on chrome
code, and XULRunner apps would benefit from having a debugger handy.
So here's what I want to do. I want to schedule a weekend meeting for 2
pm PDT Saturday [1] at #venkman on moznet [2]. The goal, as I see it, is
to plan fixing Venkman so it is usable on the XULRunner 1.9 platform.
(Getting it working on Firefox 3 would be a nice thing, too.) I want to
see who's willing to contribute hours (weeks, more likely) of coding
and/or reviewing to this goal. In particular, I'm worried about trying
to find out whatever API changes are needed in Venkman itself (not what
API Venkman has to call) and getting them in before 1.9 branches.
Watch my weblog [3] for more details; I'll write up a draft plan for the
meeting, so we have some things to think about.
[1]
http://www.timeanddate.com/worldclock/fixedtime.html?year=2007&month=9&day=1&hour=22&min=0&sec=0
[2] irc://irc.mozilla.org/#venkman
[3] http://weblogs.mozillazine.org/weirdal/
Alex Vincent
John J. Barton
some progress in adapting Firebug to debug Firefox extensions and to
have it run on FF3. Most of the needed changes for extensions will also
apply to XUL apps; the only major difference is the start-up logic.
At this point there might be more Firebug expertise than Venkman
expertise and considerably more users; rather than bitrotted, Firebug is
arguably better positioned to deal with new issues like css and dynamic
code.
John.
Gijs Kruitbosch
Venkman has (profiling? freezing js execution in other windows? ignoring
files while debugging? setting evaluation objects? pretty print?), and
the code is generally speaking harder to hack than Venkman (at least,
several people seem to believe this). From a security perspective, some
of Firebug's features (notably console logging etc.) are also a bit
problematic at the moment (see version history for 1.02 and 1.03 on
addons.mozilla.org).
~ Gijs
John J. Barton
> On the other hand, it has perhaps about 30% of the JS debugging features
> Venkman has (
> profiling?
Implemented
> freezing js execution in other windows?
I guess you mean breakpoints? Implemented. Other windows is part of the
extension support (Chromebug) I am working on this.
> ignoring files while debugging?
? I don't know what this means.
> setting evaluation objects?
Watch is implemented
pretty print?
I use it for browser-generated event handlers, but general use of pretty
print is not implemented.
>), and
> the code is generally speaking harder to hack than Venkman (at least,
> several people seem to believe this).
True, but Venkman is not a cake walk either.
> From a security perspective, some
> of Firebug's features (notably console logging etc.) are also a bit
> problematic at the moment (see version history for 1.02 and 1.03 on
> addons.mozilla.org).
The current release is 1.05 and 1.1 is almost in beta.
On the other hand, Venkman does not support eval() debugging,
browser-generated event handlers, CSS errors, CSS state, HTML state,
break-on-top-level, net traffic analysis or FF3.
But I don't think the feature list is so important since they can be
made similar. Both programs are frankly mysterious because they rely on
poorly documented underlying APIs. In fact Venkman is in my experience
the best documentation we have for JSD. In a perfect world I'd like to
see both up to speed. But in reality we have only a few people who can
work on these, so I want to be sure you know about Chromebug so you can
consider that alternative.
Gijs Kruitbosch
> Gijs Kruitbosch wrote:
>> On the other hand, it has perhaps about 30% of the JS debugging
>> features Venkman has (
>
>> profiling?
> Implemented
But you can't save profiles (or at least, you couldn't the last time I
used it).
>
>> freezing js execution in other windows?
> I guess you mean breakpoints? Implemented. Other windows is part of the
> extension support (Chromebug) I am working on this.
No, I mean stopping JS from executing at all, effectively freezing the
window (stopping the user from interacting with it at all). Last time I
checked, Firebug doesn't do this.
>
>> ignoring files while debugging?
> ? I don't know what this means.
If you use stop for exceptions or errors, or log exceptions or errors (3
out of 4 of those are not possible in Firebug, fwiw...), you sometimes
want to ignore certain files because they keep throwing random errors
you don't give a ... about.
>
>> setting evaluation objects?
> Watch is implemented
No, this is setting an object so that variables are resolved as
properties on that object, and |this| refers to the object.
> pretty print?
> I use it for browser-generated event handlers, but general use of pretty
> print is not implemented.
>
>> ), and the code is generally speaking harder to hack than Venkman (at
>> least, several people seem to believe this).
> True, but Venkman is not a cake walk either.
>
>> From a security perspective, some of Firebug's features (notably
>> console logging etc.) are also a bit problematic at the moment (see
>> version history for 1.02 and 1.03 on addons.mozilla.org).
> The current release is 1.05 and 1.1 is almost in beta.
>
> On the other hand, Venkman does not support eval() debugging,
Pretty print...
> browser-generated event handlers,
> CSS errors, CSS state, HTML state,
No, because it's a *javascript debugger*. You have DOMI for all of that,
and Venkman works with DOMI in inspecting dom nodes (if you get a trunk
build of venkman, anyway).
> break-on-top-level,
It does (assuming you mean setting breakpoints in __toplevel__).
> net traffic analysis
No, because it's a *javascript debugger*
> FF3.
That's because it's unmaintained, this will be fixed soon, hopefully.
Also, the same goes for released versions of Firebug.
>
> But I don't think the feature list is so important since they can be
> made similar. Both programs are frankly mysterious because they rely on
> poorly documented underlying APIs. In fact Venkman is in my experience
> the best documentation we have for JSD. In a perfect world I'd like to
> see both up to speed. But in reality we have only a few people who can
> work on these, so I want to be sure you know about Chromebug so you can
> consider that alternative.
Noted. I'm helping out Venkman because I'm afraid it might die
otherwise. That doesn't seem to be the case for Firebug at all. Given
I'm still a fulltime student (in his final, ie thesis-writing, year) who
is also doing a grant project involving other code in the mozilla
universe, I simply don't have (enough) time to spend on Firebug or its
derivatives.
<snip>
~ Gijs
John J. Barton
> John J. Barton wrote:
>> Gijs Kruitbosch wrote:
>>> On the other hand, it has perhaps about 30% of the JS debugging
>>> features Venkman has (
>>
>>> profiling?
>> Implemented
>
> But you can't save profiles (or at least, you couldn't the last time I
> used it).
If you mean "write a copy of the profile info to disk", you are correct
that Firebug does not do this.
>
>>
>>> freezing js execution in other windows?
>> I guess you mean breakpoints? Implemented. Other windows is part of
>> the extension support (Chromebug) I am working on this.
> No, I mean stopping JS from executing at all, effectively freezing the
> window (stopping the user from interacting with it at all). Last time I
> checked, Firebug doesn't do this.
I'm curious: what is this good for?
>
>>
>>> ignoring files while debugging?
>> ? I don't know what this means.
>
> If you use stop for exceptions or errors, or log exceptions or errors (3
> out of 4 of those are not possible in Firebug, fwiw...), you sometimes
> want to ignore certain files because they keep throwing random errors
> you don't give a ... about.
Errors are logged and Firebug->Script->Options->BreakOnErrors stops for
errors. The rest is correct.
>
>>
>>> setting evaluation objects?
>> Watch is implemented
> No, this is setting an object so that variables are resolved as
> properties on that object, and |this| refers to the object.
Sorry I don't know what this means. Can you tell me how it is used?
>
>> pretty print?
>> I use it for browser-generated event handlers, but general use of
>> pretty print is not implemented.
>>
>>> ), and the code is generally speaking harder to hack than Venkman (at
>>> least, several people seem to believe this).
>> True, but Venkman is not a cake walk either.
>>
>>> From a security perspective, some of Firebug's features (notably
>>> console logging etc.) are also a bit problematic at the moment (see
>>> version history for 1.02 and 1.03 on addons.mozilla.org).
>> The current release is 1.05 and 1.1 is almost in beta.
>>
>> On the other hand, Venkman does not support eval() debugging,
> Pretty print...
>
>> browser-generated event handlers,
>
>
>> CSS errors, CSS state, HTML state,
> No, because it's a *javascript debugger*. You have DOMI for all of that,
> and Venkman works with DOMI in inspecting dom nodes (if you get a trunk
> build of venkman, anyway).
Yes, most of javascript acts to create/modify CSS/HTML/XUL so closer
integration is helpful now and I believe a great potential for better
debugging. For example I want to break when a node is modified.
>
>> break-on-top-level,
> It does (assuming you mean setting breakpoints in __toplevel__).
No, I mean break on the next top level without manually setting
breakpoints on each __toplevel__.
>
>> net traffic analysis
> No, because it's a *javascript debugger*
>
>> FF3.
> That's because it's unmaintained, this will be fixed soon, hopefully.
> Also, the same goes for released versions of Firebug.
>
>>
>> But I don't think the feature list is so important since they can be
>> made similar. Both programs are frankly mysterious because they rely
>> on poorly documented underlying APIs. In fact Venkman is in my
>> experience the best documentation we have for JSD. In a perfect world
>> I'd like to see both up to speed. But in reality we have only a few
>> people who can work on these, so I want to be sure you know about
>> Chromebug so you can consider that alternative.
>
> Noted. I'm helping out Venkman because I'm afraid it might die
> otherwise. That doesn't seem to be the case for Firebug at all. Given
> I'm still a fulltime student (in his final, ie thesis-writing, year) who
> is also doing a grant project involving other code in the mozilla
> universe, I simply don't have (enough) time to spend on Firebug or its
> derivatives.
Unfortunately the reality is similar for Firebug: I am helping out
because it might die otherwise.
Anyway please continue to discuss Venkman issues on this group. I might
be able to help based on experience with Firebug.
>
> <snip>
>
> ~ Gijs
Adam L. Peller
> > On the other hand, Venkman does not support eval() debugging,
> Pretty print...
Huh?
I think John's reference was to the fact that Venkman behaves
strangely when debugging code which came from an eval statement.
https://bugzilla.mozilla.org/show_bug.cgi?id=332176
Perhaps it seems like an edge case, but it's my little pet peeve, and
it makes my life difficult since Dojo does pretty much everything
through XHR + eval. That loading paradigm is useful enough that it
might help provide interoperability for other toolkits as well --
http://www.openmv.com/tests/dojo-ext-jquery.html
http://dojotoolkit.org/2007/08/29/yojo-loading-yui-dojo-loader
John went through hoops to work around this problem and make it work
in Firebug, and the same technique can probably be employed in
Venkman, though the right fix, IMO, is to fix jsd (sigh... we already
know that's nearly impossible)
-Adam