TB extension development - debugging/testing

Kent James kent at caspia.com
Thu Sep 29 17:50:52 UTC 2011


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