On several occasions I've now seen the FireBug debugger doing some really strange things when stepping into certain conditional blocks.

For example I was just working on the following code that is a generic JSON callback handler in wwScriptLibrary - one of the things it does is check the result for a WCF 3.5 MS AJAX style response by checking for the specific type vars and automatically turning that object into a 'clean object' (see my last post on WCF and JSON for details).

    this._onReadyStateChange = function()
    {
        if (_I.Http == null || _I.Http.readyState != 4)
            return;

        var ErrorException = null;
        var Result = _I.Http.responseText;        
        
        if (_I.Http.status != 200)
            ErrorException = new CallbackException(_I.Http.statusText); 
        _I.Http = null;

        if (_I.evalResult){
            try{
                Result = JSON.parse( Result); 
                debugger;
                
                if ( Result.x && Result.d.__type)                
                    Result = Result.d;                
            }
            catch(e) { ErrorException = new CallbackException(e); }        
        }

        if (ErrorException)
        {
                 if (_I.errorCallbackFunction)
                         _I.errorCallbackFunction(ErrorException,_I);
                 return;
        }        
        
        if (_I.callbackFunction)
            _I.callbackFunction(Result,_I);
    }

The code in question is in bold above and it basically deals with checking for the specific types existing on the JSON decoded result value. Note the debugger; step point.

When stepping into this code I explicitly changed Result.d to Result.x in the code to see the failure scenario. When I did this though I found that the debugger stepped into the following Result = Result.d anyway! WTF?

Since JavaScript has a bazillion different ways to check for null or non-existance I start going through different checks - typeof(Result.x) != "undefined" Result.x !=null etc. etc. To no avail - FireBug keeps stepping right into that code below the IF even though the watch window clearly shows the expression on the IF to be FALSE.

Finally in desperate if (false) and that DOES work skipping the expression. Result.x or !Result.x or any of the other expressions based on Result.x cause the IF to fire.

After some more back and forth I finally realized that this appears to be a bug in the debugger. The debugger shows the code inside the IF firing but if I check the actual value of Result after that step I can see Result has NOT actually changed. Even if the debugger shows that the assignment in the IF block was made the actual value assignment (Result=Result.d) doesn't occur if the expression is false.

Aaaaargh... This isn't the first time I've seen something like this although I've never had the patience to try follow through and find WHY this was happening. It almost looks like there's some sort of optimization happening in the JavaScript code that FireFox may not be seeing.

It gets even weirder if I do something like this:

            Result = JSON.parse( Result); 
            debugger;
            var x = 0;
            if ( Result.x && Result.x.__type)    
            {            
                 Result = Result.d;                
                 x++;
            }

The debugger now jumps into the IF block, skips over the Result = Result.d, hits just the x++ - when the code comes out on the next line outside of the IF x = 0. Crazy... <shrug>

Incidentally Visual Studio debugs this correctly and skips over the expression.

This should always be the first rule of engagement - when seeing questionable results try another tool first just to be sure the tool isn't buggy. When it comes to any JavaScript or Browser related you can't trust any single tool for everything and first verifying that there's a problem with many tools can save you a half an or so of grief.

Now if I only would take my own advice sometimes...