TB extension development - debugging/testing

gNeandr neandr at gmx.de
Thu Sep 29 18:23:15 UTC 2011

Hi Kent,
thanks for your feedback. Good points -- hope also there are ears for 
those calls about tools for testing and debugging. Can't imagine 
newabies will stay long for extension development with those big hurdles.

One point, you spoke about "the testing tool addon "Extension Test" that 
just makes it much easier to see addon problems. "
Do you have any pointer/link for that?

To repeat, the real big problem is the complexity of XUL, which is very 
powerful, but needs a good understanding of it's bells and whistles 
*AND* the tuning with CSS. But right here we are left very much alone. 
Chromebug was/is a big win, but nowadays not a real help .. if you don't 
go back to earlier app versions -- as said before.

So, I repeat my request to this point, more to the audience.


On 29.09.2011 19:50, Kent James wrote:
> On 9/29/2011 2:50 AM, gNeandr wrote:
>> As an contributor for ReminderFox I'm faced with problems caused by 
>> the new release cycles and higher requirements for coding standards 
>> (which is OK, basically to make better quality and stability).
> Some of the change in "coding standards" comes from the release of the 
> testing tool addon "Extension Test" that just makes it much easier to 
> see addon problems. I strongly encourage any addon authors to use that 
> themselves to test their addons for various problems before review. 
> (Of course this indirectly reinforces your main point, that improved 
> tools can make a big difference.)
> The coding standards issue is also directly related to the timing of 
> the review process. For TB-only addon updates (that I mostly review), 
> the wait time for review is usually 4-8 days, and any problems that 
> existed in previously approved versions usually are not a cause for 
> rejection, but rather a requirement to fix before the next update.
> For Preliminary Review and Full review of new addons, the situation is 
> quite different. The wait time now is an untenable ~35 days for 
> Preliminary Review, and ~55 days for full review. Coding standard 
> issues in new addons that do not cause serious security issues will 
> pass Preliminary Review, but not Full Review, with the result that new 
> addons take many, many months to get past review. This is a serious 
> problem, but the root cause is the long wait, not the coding standards 
> themselves.
>> To hold pace with the release cycles we need testing tools!
>> We had Venkman -- that's not running smoothly, only after tuning the 
>> installation, but can be used for JS only
>> We had Firebug/Chromebug. There is no known working combination of 
>> versions for TB/FX > 3.x.
>> And for Chromebug the development process stopped.
> I think you are talking about development tools. xpcshell tests and 
> mozmill tests both work with extensions. I personally use xpcshell 
> tests extensively in my major addon under development.
>> So how to debug, trace JS/CSS in a fast moving world like FX/TB 
>> 6,7,8,9 ?
>> I hope there are good answers.
> There are not. Here's what I use for js tracing, which is kind of 
> scary. I have a standard js utility called "catchme()" which I can add 
> at any point in the js script. That function is:
> // Used to set a C++ break in a js routine
> function catchMe()
> {
>   let messenger = 
> Cc["@mozilla.org/messenger;1"].createInstance(Ci.nsIMessenger);
>   try {
>     messenger.navigatePos = 10000;
>   } catch (e) {}
> }
> I can use a C++ debugger (VisualStudio for me) to set a breakpoint in 
> nsMessenger::SetNavigatePos, and I can then see the C++ call stack as 
> well as call DumpJSStack() to see the js call stack. Also, I use a 
> standard short error routine re() in js functions that dumps the js 
> stack if called, and I use like:
> function iMightHaveAnError() {
>   // some error
> } catch(e) {re();}}
> This is all far from perfect. I, like you, wish that the development 
> tools had more priority.
> As for the rapid updates, yesterday was "Update to Moz9" day for me. 
> The first aurora 9.0a2 build came out this morning, and I had the 
> binary extensions TweeQuilla/New Account Types and ExQuilla already at 
> least running on them. My next binary releases will support Tb 7, 8, 
> and 9 (each with their own dll). Extension development is done in 
> aurora. I have been running beta personally for TB, but I think I need 
> to start running on aurora to get my extension testing done in a more 
> timely manner for my other extensions. I think this is needed to fully 
> support addons, but I don't claim it is reasonable.
> I think it is fair to say that rapid update is not popular with either 
> addon authors, or addon editors.
> rkent

More information about the tb-planning mailing list